Remote Diagnostic System for Leisure-Boat Engines

PETER ANDERSSON AND JONAS LINDVALL

Department of Signals and Systems

Chalmers University of Technology Göteborg, Sweden, 2006 EX004/2006

ii

Preface

This thesis project was performed in collaboration with Johan Oskarsson who works as an engineer at Volvo Penta in Lundby, Gothenburg. The work took place at Volvo Penta Customer Support Department, where Johan was looking for an idea that could make the progress easier during diagnostic work concerning leisure-boat engines which often includes unwanted travel. This was a perfect opportunity for us to try out our knowledge after four years of studies at Chalmers University of Technology for a Master of Science in Electronic Engineering. We would like to thank our supervisor Johan Oskarsson at Volvo Penta, for giving us the opportunity to carry through this master’s thesis project. Further, we would like to thank Jonas Kuschel at IT University of Gothenburg and Lena Peterson for their assistance and of course everyone at Quality Action Centre for provided contacts and resources.

Peter Andersson

I would like to thank my family and friends for there support during this report. I wouldn’t have come this far without your encouragement. This thesis project has been an amusing but very demanding task and taken more energy than I ever could imagine. In return I have taken a firm step into the future. Thank you all for making this possible.

Jonas Lindvall

I would like to thank my lovely girlfriend Leyla for her patience. I have not been easy to live with during this work. I must say that this has been more challenging than I could ever imagine. I would also like to thank my whole family and my friends for their support during this time. Everyone has been so nice to me. I hope I can make it up to you all sometime.

iii

Summary

Progress in telematic and wireless communication systems, with new developments occurring almost daily, makes it possible to reach almost every corner of the world. Remote vehicle diagnostics is a type of telematic service that provides opportunities to conduct vehicle diagnostics work remotely. Remote-diagnostics systems can provide mechanics with vital information that can help to anticipate engine errors before they occur, help the technicians prepare for repairs and provide technicians and personnel with engine-related information. The use of such systems could lead to more effective service and repairs and less travel expenses. However, the full potential of a remote-diagnostic system is not known yet. This thesis is the result of a research project with the initial purpose of finding an existing telematic system for remote diagnostics. The result of our market research made us change focus to find a whole new system design with purpose to increase the efficiency in diagnostic work. The major results of this work are the remote-diagnostic system design and the market launching model, developed in collaboration with future system users. In the conclusion we present an idea of how a system can be designed based on needs expressed by several categories of potential users. Further, we present our idea of how to launch this kind of system into the aftermarket.

iv

Table of Contents 1 INTRODUCTION........................................................................................................................................ 1

1.1 BACKGROUND ........................................................................................................................................ 1 1.2 PURPOSE................................................................................................................................................. 1 1.3 LIMITATIONS .......................................................................................................................................... 2 1.4 PROBLEM DEFINING ............................................................................................................................... 2 1.5 OUTLINE................................................................................................................................................. 2

2 FRAME OF REFERENCE ......................................................................................................................... 4

2.1 TELEMATICS........................................................................................................................................... 4 2.2 DIAGNOSTICS ......................................................................................................................................... 4

2.2.1 Diagnostic at Volvo Penta ................................................................................................................ 5 2.3 REMOTE DIAGNOSTIC ............................................................................................................................. 5

2.3.1 Centralized approach ....................................................................................................................... 6 2.3.2 Decentralized approach.................................................................................................................... 6

2.4 END CUSTOMER ...................................................................................................................................... 6

3 METHOD...................................................................................................................................................... 8

3.1 LITERATURE STUDIES ............................................................................................................................. 9 3.2 INTERVIEWS ........................................................................................................................................... 9

4 TECHNICAL FRAMEWORK................................................................................................................. 11

4.1 ELECTRONIC DIESEL CONTROL – EDC................................................................................................. 11 4.1.1 Diagnostic Software for the EDC control unit .............................................................................. 12

4.2 ELECTRONIC VESSEL CONTROL – EVC................................................................................................ 12 4.3 DIAGNOSTIC TROUBLE CODE – DTC.................................................................................................... 13 4.4 ENGINE INTERFACE .............................................................................................................................. 13 4.5 SAE J1939 CAN LINK.......................................................................................................................... 13 4.6 CONTROL AREA NETWORK – CAN ...................................................................................................... 14 4.7 CONTROL INTERFACE UNIT – CIU........................................................................................................ 15 4.8 BLUETOOTH ......................................................................................................................................... 15

4.8.1 Overview of Bluetooth .................................................................................................................... 15 4.8.2 General Interaction ........................................................................................................................ 15

4.9 3G ........................................................................................................................................................ 16 4.9.1 TDMA ............................................................................................................................................. 16 4.9.2 CDMA ............................................................................................................................................. 17 4.9.3 EDGE.............................................................................................................................................. 17

5 EXISTING SYSTEMS............................................................................................................................... 18

5.1 COMMERCIAL SYSTEMS ........................................................................................................................ 18 5.1.1 GM´s OnStar .................................................................................................................................. 18 5.1.2 Volvo OnCall .................................................................................................................................. 19 5.1.3 SeaKey ............................................................................................................................................ 20 5.1.4 Volvo Penta Action Service ............................................................................................................ 20

5.2 DEVELOPMENT ..................................................................................................................................... 21 5.2.1 CANSAS-PRO ................................................................................................................................ 21

5.3 CONCLUSIONS ...................................................................................................................................... 21

6 TELEMATIC SOLUTIONS ..................................................................................................................... 23

6.1 CAN TO BLUETOOTH ........................................................................................................................... 23 6.1.1 System picture................................................................................................................................. 24

6.2 RESULT ................................................................................................................................................ 24 6.2.1 Bluetooth ........................................................................................................................................ 24

6.3 CONCLUSION ........................................................................................................................................ 25

7 METHOD FOR REMOTE DIAGNOSTICS........................................................................................... 26

v

7.1 DIAGNOSTIC WORK TODAY................................................................................................................... 26 7.1.1 Remote collaboration ..................................................................................................................... 27

7.2 CONCLUSION ........................................................................................................................................ 29

8 REMOTE DIAGNOSTIC EXAMPLES .................................................................................................. 33

8.1 SYSTEM DESIGN ................................................................................................................................... 33 8.2 CAN-BT GATEWAY IMPLEMENTATION................................................................................................ 34 8.3 SCENARIOS ........................................................................................................................................... 35 8.4 BENEFITS.............................................................................................................................................. 38

8.4.1 Boat owner/Customer..................................................................................................................... 38 8.4.2 Local Technician/Dealer................................................................................................................ 38 8.4.3 Central Expert ................................................................................................................................ 38

8.5 FURTHER RVD SCENARIOS .................................................................................................................. 39

9 MARKETING ............................................................................................................................................ 41

9.1 ECONOMY MEASURE ............................................................................................................................ 41 9.1.1 Cost of implementation .................................................................................................................. 41 9.1.2 Cost saving...................................................................................................................................... 41

9.2 SOLUTION DETAILS............................................................................................................................... 41 9.3 RISK MANAGEMENT............................................................................................................................. 42 9.4 VOLVO PENTA HEAD QUARTER ........................................................................................................... 43 9.5 BUSINESS EMISSION ............................................................................................................................. 43 9.6 CONCLUSIONS ...................................................................................................................................... 44

10 FUTURE WORK................................................................................................................................... 45

10.1 FUTURE APPLICATIONS ........................................................................................................................ 45 10.2 FUTURE VISIONS ................................................................................................................................... 45

11 CONCLUSIONS .................................................................................................................................... 46

11.1 VISION.................................................................................................................................................. 48

12 REFERENCES....................................................................................................................................... 49

12.1 PERSONAL REFERENCES ....................................................................................................................... 49

vi

Terminology

ACK: Acknowledgement CAN: Controller Area Network CIU: Control Interface Unit

CDMA: Code Division Multiple Access

CRC: Cyclic Redundancy Check CSMA/CD: Carrier Sense Multiple Access Collision Detection

D12: 12 liters diesel engine ECU: Electronic Control Unit

EDC: Electronic Diesel Control EDGE: Enhanced Data GSM Environment EMS: Engine Management System EVC: Electronic Vessel Control GPRS: General Pocket Radio Service GPS: Global Positioning System GSM: Global System for Mobile HCU: Helm Control Unit MS: Multi Station PCU: Power train Control Unit

PDA: Personal Digital Assistant

RVD: Remote Vehicle (alt. vessel) Diagnostic

SAE: Society of Automotive Engineers

SMS: Short Messages Service

TDM: Time Division Multiplexing

TDMA: Time Division Multiple Access

vii

Vodia: Diagnostic software for PocketPC based PDA VP: Volvo Penta

WAP: Wireless Application Protocol

1

1 INTRODUCTION

This chapter will give the reader a general view of the background, purpose and limitations of the work.

1.1 Background

This master’s thesis project was performed at Volvo Penta (VP) in Gothenburg. Volvo Penta is a world leader manufacturer of engines and complete driving system for marine and industrial purposes. The engine program comprises diesel and petrol engines in output ranges of 10-2000 hp. Volvo Penta is a part of the Volvo group, one of the world’s largest manufacturer of trucks, buses, construction machines, driving system for marine and industrial applications and also components and services for aircrafts and aircraft engines. A modern vehicle, such as a car or boat, is to a large extent controlled by computers, called Electronic Control Units (ECUs), which are interconnected via a serial bus. The common name for a VP engine’s all ECUs, including drive control levers, control panels and cables, is the vessel’s Electronic Vessel Control (EVC) system. Each ECU controls different parts of the vessel and can be programmed to behave in different ways. The possibility to program each unit makes it possible to calibrate the different parts to operate in most effective ways i.e. optimize the amount of fuel injected into the cylinders. It is also possible to detect abnormalities in an effective way. Data values not in accord to predefined accepted values automatically generate so-called Diagnostic Trouble Codes (DTCs) that are stored in the ECUs. To perform a full service, technicians have to connect a computer with advanced computer programs which can update the ECUs software, display requested status parameters and DTCs. In the marine industry, as in the vehicle industry in general, companies are showing an increased interest in Remote Vehicle Diagnostic (RVD). Today there are some examples of commercial services, such as GM’s OnStar, Volvo OnCall and VP’s SeaKey for marine purpose, that all focus on customer needs such as road assistance and guidance. Our task is to design an RVD system, from an already existing system, that adapts to Volvo Penta needs.

1.2 Purpose

A good way to approach a problem is to consider the underlying needs and try to identify the real purpose. One can find the right way to solve a problem by splitting the purpose in different layers and searching for the right approach. Purposes always create different layers, where one specific purpose is an instrument to accomplish something at the next layer. To find a way to move up and down in layers makes it possible to find creative solutions. There is no “correct” way to approach a problem but there is always a layer, often higher than the first suggested, that really explains what to do. This layer gives a number of possible solutions, some of them maybe never considered. Thus, it is important to make small steps to be able to find a middle layer between the first ones considered, Marttala & Karlsson [1].

2

Figure 1.1 Levels of purposes

The project purpose is to deliver a business case for a relevant VP product. The business case shall include cost of implementation, required changes of existing products and a description of modules included. This project is supposed to be a part of a reference document for future implementation of an RVD system.

1.3 Limitations

The research concentrates on the boat and vehicle market. As the name Remote Diagnostic suggests, it means diagnostic of an object from a remote geographical location. Remote Diagnostics is represented in a lot of fields, all from manufactory industry where data from machines bound to the manufacturer process is accessible, to the airplane industry where the demands of perfect functionality are high. The functionality and cost vary among these different systems. Our research is limited and includes the vehicle and heavy-vehicle markets where telematic and remote diagnostic are emerging and have been so for a couple of years. The vehicle market and the leisure-boat market are similar when it comes to the engines, where the same engines that are used in trucks and cars are also used in boats. To decrease the project scope the leisure-boat segment was chosen. Since the engine we aim at must be equipped with EVC system, we concentrate on dealers and customers who handle such engines. Research and interviews have been made at the Swedish west coast.

1.4 Problem Definition

1. What different RVD systems are available at the market? 2. How can an RVD system be implemented in the EVC system? 3. What changes are required from a Volvo Penta point of view? 4. What are the technical requirements for an RVD system to satisfy VP?

1.5 Outline

In chapter 2 we give the reader an overview of the subject diagnostic and fields directly related. Here the reader can get a first picture of what the field remote diagnostic involves and what have been done in the field so far. The chapter also informs about different approaches

3

to remote diagnostics. Chapter 3 gives the reader a insight in how the work has been carried out, that is methods for gathering data and also an evaluation of the reliability of the result. We have decided to present our work in a chronological way with a conclusion section in each chapter that explains results and further actions. The next following chapter is therefore a direct consequence of the conclusion and result from the chapter before. In chapter 5 we first present remote diagnostic systems available on the market today and related functions. Chapter 6 focuses on telematic solutions for short-range data communication and chapter 7 handles methods for performing remote diagnostic in an effective way with today’s diagnostic work in mind. Chapter 5 to 7 then conclude with chapter 8 where a remote diagnostic system is presented. In chapter 8 facts and results from previous chapters are taken into consideration and form a basis for the out coming system. A number of scenarios show the reader how the system can be used in reality. The later parts as chapter 9 present the Volvo Penta organization and an inquiry of the ultimate user, that is the target group for the system proposal. Here is also a proposal for how the marketing of the system can be made. The report concludes with chapter 10 that presents possibilities for future applications and upgrades for the system, followed by overall conclusions in chapter 11.

4

2 FRAME OF REFERENCE

2.1 Telematics

The world market of vehicle telematics and fleet management solutions for professional and private markets is today estimated to $5 billion, with annual rates forecasted to 50% [7]. In an early stage of telematic solutions, safety and route guidance were the range of practicable services in the telecommunication industry. A telematic service of today includes many different areas, such as Internet-based information systems, fleet management, vehicle diagnostics and much more. An example of a common telematic service of today is navigation systems such as Global Positioning System (GPS), which have been available for the last five years in most modern vehicle. It is generally hard to define telematics, but it is often referred to as the convergence of telecommunication and informatics [8].

2.2 Diagnostics

Diagnostics is a procedure or program that is run internally to test a piece of software or hardware and to ensure that it is operating properly. For example, if R2-D2 of Star Wars decided to start running into walls, C3PO would probably make him run diagnostics on himself to try to figure out what his problem was. Diagnostics have been changed over the years, from being a technician’s instincts of engines behavior to today’s computer-controlled engine systems, which need computerized diagnostic tools to make an understandable diagnosis. Problems that can occur with today’s diagnostics are that it often identifies the effect of the problem instead of the actual cause. This is a difficulty for developers of these kinds of tools. Diagnostics of engine signals are today standardized according to Society of Automotive Engineers (SAE). Before the standardization, each developer had its own system for communication between different electrical components. To make a diagnostic check of an engine, a diagnostic tool is connected to the serial bus. The serial bus is connected to all ECUs where the Diagnostic Trouble Codes (DTCs) are stored automatically. Today most repairs are still done without DTCs, but the number of EV- equipped boats is growing quickly. Most of the marine service work of today takes place during off-season. A service or repair work is not finished until a test run is made to control that the engine works properly. The data from this test run is a good reference if an error occurs during season. Hamilton [3] presents an organized perspective and description of diagnostics. He claims that diagnostics, from a general point of view, should answer three main questions: Are there any problems? What is the problem? What possible actions can be taken? Hamilton also presents four different steps that are taken in a diagnostics cycle. 1. Failure – Deviating behavior in a system component. 2. Detection – Internal, embedded diagnostics systems that monitor deviations. These can be either hardware or software solutions.

5

3. Diagnosis – Analysis of the collected data from the embedded system. Information that indicates “what” is wrong but not the “cause”. 4. Recovery – The necessary actions to be taken based on collected diagnostics data. Improving diagnostics is a common interest for customer and technicians, if technicians could lower downtimes with fast and precise diagnostics higher customer satisfaction could be reached.

2.2.1 Diagnostics at Volvo Penta

The traditional usage of diagnostics functions concerns reading error messages from the boats on-board system memory, read-outs of engines parametric data and reprogramming of ECU software. Today’s access of technical information from the boat gets available from the Volvo Penta diagnose tool VODIA. VODIA is a PDA application, developed for Volvo Penta’s aftermarket. It supports the new engine systems and makes it possible to trace faults, perform tests and reprogram the control units. The user connects the PDA to the boat via a special hardware interface. The VODIA system also contains a web application on Volvo Penta Partner Network where the user can download software and update the PDA application. It was released in 2002 and will be in use at most Volvo Penta dealers around the world. The software on the client, which is a PDA with operating system PocketPC 2002, is developed in Embedded Visual C++.

Figure 2.1 PocketPC based PDA with Vodia software

2.3 Remote diagnostic

Marine and vehicle industry companies show an increasing interest in Remote Diagnostics, which often are described as accessing, diagnosing and programming vehicle systems remotely [12]. Early telematics applications focused primarily on services related to route guidance and safety, but lately telematics has come to include a broad range of services with many different application areas like fleet management, internet enabling services and vehicle diagnostics. Remote diagnostic market is in a strongly growing phase, and it is generally considered as one of the most important telematics services in the future, were more and more market get involved, both product developers and the aftermarket. Engine systems become more and more computerized and therefore problems and solutions are nowadays often

6

related to digital technology like ECUs, and information like DTCs. The reason why remote diagnostics has not been used earlier in the vehicle industry is related to the technology progress. The technology has reached a phase where it is possible to offer relatively cost-effective telematic solutions passable for the aftermarket. This has made it economically possible for companies to investigate the remote-diagnostics usage in there company. Market analysts Frost & Sullivan define remote diagnostics as the ability to access the vehicle’s performance parameters and trouble codes in case of malfunction using a wireless network, and provide necessary support services [13]. According to a recent survey by InfoMove, a Seattle provider of personalized, location-based applications and wireless services for automobiles, 73 percent of consumers would like automakers and dealers to be able to diagnose car problems remotely [4].

2.3.1 Centralized approach

Today’s remote diagnostic systems are mostly restricted to service centers, where technically skilled personal are trying to correct problems via phone. When problems occur that they cannot correct, a service technician are contacted. Today, GM’s OnStar, Volvo OnCall and VP’s SeaKey for marine purpose are all within this category; all focus on customer needs such as road assistance and guidance. These are examples of centralized approach of commercial services were the needs of the service technician have not been in focus.

2.3.2 Decentralized approach

A decentralized approach of remote diagnostic is to focus on the local service technician. Unlike the centralized approach the service technician should be more involved within the problem, more than only a “tool” to solve problems by repairing the engine. If the service technician is involved from start he could perform a more effective work.

2.4 End customer

VPs ambition is to make as good profit as possible. This requires selling many high-quality engines adapted to the market prices. This means that production cost must be as low as possible. Right after the engine is sold it enters the aftermarket. The aftermarket can be described as the life phase that follows after the engine is sold or put into operational use, and it continues right until the engine is made obsolete.

Figure 2.2 Engine lifetime

Possible customers of remote diagnostic services appear in all three blocks. In R&D and production phase the customer for RVD systems are VP and/or companies in cooperation with Volvo. In the last block, the aftermarket, the customers will be the users of a VP engine

Research and

Development (R&D)

Aftermarket

Production

7

i.e. the individual or company that purchases or operates the engine. The aftermarket concerns maintenance, repairs and the spare part market. For VP the maintenance work i.e. repairs and spare parts are highly profitable. The characteristic of the aftermarket is that it consists of many customers. Our ambition is to come up with an idea for an RVD-system platform aimed at the aftermarket e.g. leisure-boat owners or local technicians, in contrast to existing systems like CANSAS that aim at R&D and production.

8

3 METHOD

In this chapter we give a brief overview of progress and methods we have applied to come to a result and conclusion for this thesis. The progress of the work has forced us to use two different research methods. In the initial phase a qualitative traditional research process was applied. This was the obvious choice when the purpose was to observe and compare already existing products and methods at the RVD market. The literature studies that were done in parallel with the market research gave us a deeper understanding of the problem and new ideas came up continuously. The new problem made us change the method to a qualitative perspective of research method. The qualitative approach directs the individual, in contrast to the quantitative approach where the focus is to observe, register and measure a more or less given reality [2]. The focus of this study has been how people, i.e. technicians and Volvo Penta central experts, understand the reality when it comes to diagnostic and repairs of marine engines. Results from these interviews have been the basis for new questions and new approaches to the problem.

Figure 3.1 The traditional research process, used in the initial phase [2].

Figure 3.2 The qualitative research process, used in the later phase [2].

The information collected during the quantitative phase together with the information from the qualitative part gave us an overview of the areas of Remote Diagnostic, Diagnostic, VP-engine related electronics. We also got a deeper understanding of the repair procedure and we identified the needs from local technicians, central experts and end customers. All this

9

together led to a conclusion of the thesis. The conclusion consists of a system design of an RVD system aimed for the leisure-boat segment and an idea of how to launch to market. We believe that the changeover from a quantitative to a qualitative process was natural in this research. The quantitative phase together with the literature study can be describe as a pre-study and gave us a deep understanding and helped us identify the problem. The deeper in the research we got, the closer we got the to the core problem. The core problem was found in another layer than first expected, which forced to change approach several times. All this was made by splitting the main purpose in small pieces. This is why we think that both methods gave a satisfying result to the right problem. We got a deep understanding of what the problem really was instead of giving a satisfying answer to the wrong problem.

3.1 Literature studies

As in all scientific research we had to make extensive literature studies. When we faced the problem it was necessary to get deeper knowledge about what has been done and what has been written in the related fields. In the initiation phase we had limited knowledge of earlier work in the fields of diagnostic, remote diagnostic and wireless communication. To enter deeply into the subjects we started our work with literature studies. Literature concerning diagnosis and remote diagnostic in the marine industry is in highest grade limited why we included literature concerning the vehicle industry, where the supply is much better. Literature concerning telematics and wireless communication stand in relation with remote diagnostic, why this field was included in the studies. Fortunately, we got the opportunity to carry out this thesis work at the Volvo Penta headquarter in Gothenburg. This our location made it possible for us to get the technical information about the engines e.g. design and function of the electrical system and specific data in the internal literature and handbooks.

3.2 Interviews

The interviews took place in the qualitative phase of the research. To get an initial overview of the diagnosis and repair process we had discussions with our tutor at Volvo Penta. In collaboration with him we came up with a number of scenarios where an RVD solution hypothetically could simplify the diagnostic and repair procedure. Because local technicians had an important role in the scenarios it was necessary to get a better understanding of the technicians work in the workshops. We decided to visit local workshops in the local vicinity. The purpose of these visits were, at first, to get better understanding of the technicians work procedure, second, to get feedback on our ideas. During the visits we presented the scenarios to the local technicians and collected feedback. Based on this information we developed new ideas of how an RVD system could simplify the work of the technicians in the field. Concerning methods for remote diagnostic, Jonas Kuschel, PhD student at the ITuniversity of Gothenburg was object for consultation. He gave us valuable information from his research. His research papers, presentation and consultation gave us a much deeper insight in the field.

10

The advantage of using a qualitative approach was the possibility to discuss questions and problems. In this way the risk of misunderstandings was minimized, both from the interviewer and the person-interviewed point of view. A possible detriment could be the limited number of local technicians and central experts included in the study. They cannot answer for the whole existing group [3]. Since we limited the research to the local vicinity, we expect the result from the chosen reference group to be reliable.

11

4 TECHNICAL FRAMEWORK

Electronic devices for controlling engine electronic parts in marine industry are called Electronic Control Units (ECUs). These ECUs have several sensors attached to the engine which trigger Diagnostic Trouble Codes (DTCs) in case of abnormal data values. DTCs are parts of information used to find causes of engine problems. This chapter will explain and review different electronic and communication systems that are related to today’s Volvo Penta engine systems for leisure boats, and affect our RVD research.

4.1 Electronic Diesel Control – EDC

Volvo Penta Corporation uses a control system, which is called EDC for many of their engine systems. The Volvo Penta Electronic Control System is a single-lever system for combined operation of the throttle and gear functions in marine engines. The system comprises an electronic unit, drive unit control lever(s), control panels and cables. The system controls the fuel injection through an electrical pump. The control unit turns the engine on and controls all its functions. The control lever and the gear are controlled by a potentiometer read by the control unit. The driver seat is also equipped with a throttle, which controls the rudder with hydraulic or a wire and a button set consisting of ‘Active station’, ‘Neutral’ and ‘Diagnosis’ buttons. On each new driver seat there is a Multi Station (MS) unit connected, which communicates with the control unit through the CAN bus.

Figure 4.1 Volvo Penta EDC system

New injection systems are under development, due to constantly increasing demands on reductions of exhaust emissions and low fuel consumption from diesel engines. Fuel systems are rapidly reaching their limits. The new D12 engine family (TAD1240 – 1242GE) is equipped with the new Volvo Engine Management System (EMS) further developed by Volvo Penta and named EDC III. They have very little in common with the EDC I system

12

used on the Industrial Engines TWD740VE and TWD1231VE. Industrial D12 engines are equipped with the EDCIII system. It is controlled entirely electronically. The Electronic Control Unit (ECU) reads operating parameters from a number of sensors placed on the engine. EMS provides efficient engine management and advanced facilities for diagnostics and error tracing. Precisely controlled fuel injection makes a more efficient combustion resulting in lower fuel consumption and faster injection. The engine is equipped with 11 sensors functions in order to register operating data. The control unit (ECU) compares current readings with stored data. The fuel system components consists of the ECU, which is cooled by the fuel flow via a built-in cooling circuit, the non-return fuel valve, fuel pre-filter with water separator and water-in-fuel indicator, gear driven low-pressure fuel pump, fine fuel filter with manual feed pump and fuel pressure switch, the traditional in-line injection pump with mechanical or electric governor is replaced by individual unit injectors, overflow valve (4.5 bar). In the fuel system there are 7 sensors with 8 functions; flywheel and camshaft speed, boost temperature and pressure, coolant and fuel, fuel pressure and water-in sensor.

4.1.1 Diagnostic Software for the EDC control unit

The EDC system has an internal diagnostic function that makes it possible to detect errors in the engine. The diagnostic function is to detect and localize errors in the EDC system, protect the engine against continuing to operate during serious errors. If an error has occurred, diagnostic indicators on the indicator panel start to blink. When the diagnostic button is pressed, an error code is given for error detection. The Volvo Penta Diagnostic Software can be used for diesel engines with electronic controlled fuel injection, i.e. EDC engines. The connection to the engine control unit is through a particular diagnose socket, usually on the electronic central. The program is designed to read error codes which have been stored in the control unit.

4.2 Electronic Vessel Control – EVC

EVC is the latest development in instrumentation for Volvo Penta marine engines. In a basic Electronic Vessel Control (EVC) system there are two ECUs, one Power train Control Unit (PCU) at the engine to interface the engine and the transmission, and one Helm Control Unit (HCU) at the helm to interface gauges, key, controls etc. A helm is the control panel from where the boat is maneuvered. Another HCU, e.g. for the fly bridge, can be installed by a Y-connector on the CAN-bus since all the information is available here. The major improvement compared with EDC is that one system handles both instruments and controls. In the EVC the CAN-bus handles all communication, only one cable needs to be installed between the engine and the helms. The main purpose of an EVC system development is to decrease the number of cables installed in the boat and consequently reduce weight and misreading by error in cables.

13

Figure 4.2 EVC-system overview.

4.3 Diagnostic Trouble Code – DTC

When a failure is detected, a DTC is stored in the ECU memory, which holds information related to the specific problem and contains detailed information about the specific failure. Some DTCs are forwarded to the driver who is notified by a lamp on the dashboard or at the EVC display. Other DTCs require diagnostic tools connected to the system, to locate errors for further analysis. DTC example: MID PID DATA DATA DATA CRC 128 164 XXX XXX XXX XXX There are two starting frames in a DTC message indicating the related MID and PID. The following data frames contain information associated with the particular fault code. The last frame is a checksum.

4.4 Engine Interface

Today there are three different ways to connect controls and instruments to the engines. The CAN SAE J1939 interface, the CIU and stand-alone connections.

4.5 SAE J1939 CAN link

A standard equipped engine has an 8-pole bus interface connector to provide access to the SAE J1939 CAN link and the SAEJ1708/1587 link. The J1708 link handles the engine diagnostic and parameter setting tool, while the much faster CAN link handles the data communications.

14

4.6 Control Area Network – CAN

When electronic substance and electronic controlled functions in the car industries expanded, the electric cable networks also expanded in size as well as complexity. It became necessary to leave the old system behind for a new system where several control signals share the same cable to minimize the electric cable net. The solution was the CAN-bus. CAN was developed by Bosch and Intel in the 80’s, but it took quite a while before the car industry began to use the system. The multiplex system made the manufactures take responsibility for the electronic evolution and the electronic communication between different units in a network. The CAN-bus is of broadcast type i.e. the nodes can both listen and send messages on the bus, but cannot address one specific node. With special hardware the CAN system can filtrate and make nodes react to specific messages. It is easy to add new nodes without any changes in the software or hardware. A frame consists of a 32-bit identifier, a data field consisting of 0 to 8 bytes with data, a Cyclic Redundancy Check (CRC) field, a 15-bit checksum for error detection and a 2-bit Acknowledgement (Ack) field for confirmation. The identifier decides priority when two units want to transmit at the same time. CAN nodes can send message when the bus is free. Situations when two nodes want to send at the same time are solved by bit arbitration. The identifiers with the lowest numeric value get access to the bus.

Figure 4.3 CAN frame

The standard CAN communicates at low level and the CAN protocol specifies the transport of small packages between A and B. The standard CAN does not include flow schedule, transport of data larger than 8 bytes, node addresses or readdresses of communication. For that it needs a Higher Layer Protocol (HLP) that takes care of the start procedure, distribution of messages, translation of data and status. Volvo Penta uses a dialect protocol of the SAE J1939. The dialect has been developed by CPAC, which is the company that is the creator and developer of VP’s EVC system. The CAN system is occurrence-trigged, which means that no data processing exists without an occurrence on an in port or when a message has arrived. The bit rate is 1 Mbit/s. CAN/J1939 uses Carrier Sense Multiple Access with Collision Detection (CSMA/CD) and Arbitration on Message Priority (AMP). J1939 is designed for operation in real-time between electronic units. A real-time system must have a characteristic of a maximal ‘response time’, which is limited and countable. CAN messages are of the type ‘Data’ and ‘Remote Message’ which means request for data. The CAN protocol uses NRZ with bit stuffing, biphasic. If a controller detects a transfer error, it sends an error flag and starts a repetition of the

15

transmission. This stops the current transmission. This form of error signaling leads to short error recovery times. As mentioned earlier, CAN is based on the so-called broadcast communication mechanism. The broadcast communication is achieved by using a message-oriented transmission protocol. This means that messages sent over the network do not define stations or station addresses. Instead a specific identifier that is within the whole network recognizes each message. Due to the broadcast property all messages sent over the network are visible to all nodes, but mechanisms are provided by the protocol e.g. local filtering, forcing each node to respond only to self-concerned information. Further, each message has its own priority, thus solving the problem of several stations competing for bus access simultaneously.

4.7 Control Interface Unit – CIU

The Volvo Penta CIU is an optional equipment to the CAN link. The CIU converts the CAN protocol to analogue or digital signals and signals to CAN protocol.

4.8 Bluetooth

Bluetooth is a wireless technology for connecting different devices such as cellular phones, PDAs, laptops, keyboards, mouses etc. The name came from the Danish king Harold Bluetooth who lived between 910 and 985 AD. The Viking king Harold Bluetooth united Denmark and Norway. Bluetooth of today will unite the worlds of computers and telecom, maybe that is why it is called Bluetooth.

4.8.1 Overview of Bluetooth

The Bluetooth wireless connectivity technology was introduced in 1994 by Ericsson as a way for mobile devices to communicate with each other at short range, up to 10 meters. In 1998, Ericsson, IBM, Intel, Nokia, and Toshiba formed the Bluetooth Special Interest Group (SIG) to develop a royalty-free, open specification for short-range wireless connectivity. Since then more than 2000 companies have joined the Bluetooth SIG, including many manufacturers of mobile phones, computers, PDAs, digital cameras and voice transmission headsets. Bluetooth is a radio-frequency technology that uses the 2.4 GHz Industrial Scientific Medical (ISM) band. This band is the same as used by e.g. a garage-door opener. Bluetooth is positioned as a replacement for cable, infrared, or other connections. It is also a good technology for synchronizing devices.

4.8.2 General Interaction

A Bluetooth system consists of four interlocked layers that provide the desired functionality:

Hardware - An adapter and a suitable driver.

16

Configuration Files - Used for controlling the Bluetooth system.

Daemons - Services that are controlled by the configuration files and provide the functionality.

Applications - The applications allow the functionality provided by the daemons to be used and controlled by the user. When inserting a Bluetooth adapter, the respective driver is loaded by the hotplug system. After the driver is loaded, the system checks the configuration files to see if Bluetooth should be started. If this is the case, it determines the services to start. Based on this information, the respective daemons are started. For security reasons, the Bluetooth system is deactivated in the default configuration. Bluetooth uses frequency hopping. Its spread-spectrum approach greatly reduces the risk that communications will be intercepted. Bluetooth uses a time-division multiplexing (TDM) scheme. This will show a standard High-level view of the architecture of a Bluetooth protocol stack.

Figure 4.4 High-level view of the architecture of the Bluetooth protocol stack.

4.9 3G

3G is the third generation of mobile communications technology. It provides bandwidth up to 384 Kbps when a device is stationary or moving at pedestrian speed, 128 Kbps in a car or boat and 2 Mbps in fixed applications. 3G will work over wireless air interfaces such as GSM, TDMA, and CDMA. EDGE has specifically been developed to meet the bandwidth needs of 3G.

4.9.1 TDMA

Time Division Multiple Access (TDMA) is a technology for delivering digital wireless service using Time Division Multiplexing (TDM). TDMA works by dividing a radio frequency into time slots and then allocating slots to multiple calls. In this way, a single

17

frequency can support multiple, simultaneous data channels. TDMA is used by the GSM digital cellular system.

4.9.2 CDMA

Code-Division Multiple Access (CDMA) is a digital cellular technology that uses spread-spectrum techniques. Unlike competing systems, such as GSM, that use TDMA, CDMA does not assign a specific frequency to each user. Instead, every channel uses the full available spectrum. Individual conversations are encoded with a pseudo-random digital sequence. CDMA provides better capacity for voice and data communications than other commercial mobile technologies, allowing more subscribers to connect at any given time, and it is the common platform on which 3G technologies are built.

4.9.3 EDGE

Enhanced Data GSM Environment (EDGE) is a faster version of GSM wireless service. EDGE enables data to be delivered at rates up to 384 Kbps on a broadband. EDGE is based on the GSM standard and uses TDMA multiplexing technology.

18

5 EXISTING SYSTEMS

This chapter presents a number of systems available at the market. These services are underlying to the field of telematic mentioned in chapter 2. Telematic services used in the vehicle industry unite techniques of wireless communication, position technology, remote diagnostic and different types of entertainment and safety services in the car. A segment where such services are well established is the heavy-vehicle industry where so called fleet managers provide fleet operators with important information about driver performance, fuel consumption, diagnostics protocols and warranty-related information from trucks [9]. Downright remote diagnostic systems for the vehicle industry are today used for Research and Development (R&D) purpose. An example is Volvos CANSAS-PRO, a system for accomplishing RVD of truck and marine engines. The system collects data for test purposes and accesses the engine remotely. Volvo Dynafleet and Networkcar’s Networkfleet are examples of fleet managers with purpose of lowering the operating expenses throughout fuel control and an optimized administration. Many fleet-manager systems can also locate the vehicle in real time. Volvo OnCall, GM’s OnStar are commercial systems that provide safety and navigation for car users. More examples are NEXIQ Technologies Inc., ATX Technologies Inc., Toyota, Vetronix Inc., Jentro AG, BMW, Volkswagen, IBW, and Dearborn Group, which either already have or are developing remote diagnostics applications.

5.1 Commercial systems

5.1.1 GM´s OnStar

OnStar is a service made to meet the customer requirements. OnStar is a safety, security and information service for GM cars, using Global Positioning System (GPS) satellite and cellular technology GSM/GPRS to link the vehicle and driver to an OnStar center. At the OnStar center, advisors offer real-time personalized help at all time. If the Check Engine light turns on at the instrument panel the driver can push a button and an OnStar advisor can run a remote diagnostic check of the engine. The advisor can then help the driver with further actions such as contact roadside assistance or assist in scheduling a service appointment if necessary.

Figure 5.1 OnStar user panel

OnStar has a future purpose that allows mechanics to identify vehicle problems before it enters a workshop for service. Picture 5.2 describes OnStar´s available services and the work in progress. If customers choose not to buy OnStar as an extra feature the access of RVD fail. We argue that an RVD service should be a standard in the vehicle or vessel and not depend on

19

customer choices. Systems similar to OnStar do not fit in as an RVD system for our purpose but could work as a complement.

Figure 5.2 GM’s OnStar system overview

5.1.2 Volvo OnCall

Volvo OnCall is a core part of Volvo’s philosophy for an uncompromised approach to safety. Volvo OnCall is available in Volvo cars and works as a road assistant. The service collects and organizes detailed performance and location-based information directly from the vehicle engine computer and a global positioning system (GPS). This information is then transmitted wirelessly from the vehicle and made available to Volvo OnCall service center or website for fleet manager purpose [10]. OnCall system is very similar to OnStar and also a commercial system that follows the same principles. This fact makes Volvo OnCall a non-suitable RVD-system solution for a general implementation at VP engines.

Figure 5.3 Volvo OnCall system overview

20

5.1.3 SeaKey

SeaKey is a communication system that provides satellite connectivity and works as a control and alarm service for marine vessels. The system connects electronic equipment to internet for remote monitoring. SeaKey provide security and not technical information concerning the engine. “SeaKey provides instant communication to the 24 hour, 7 day per week SeaKey response center, and communicating requests for a number of situations” such as those listed below [11].

• Boat stolen • Water intake • Concierge services • Low battery • Lost / need directions / bad weather • Mechanical malfunction • Out of fuel / run aground • Tracking

Figure 5.4 SeaKey user control Developers of SeaKey have plans of adding a CAN-bus connection. So far the system gets data only from external sensors and this is one of our reasons for rejecting it. Another reason is the usage of satellite communication, which, in our opinion, is excessive when oral communication is necessary. The system is made for aftermarket and focuses on customer use; the implementation is expensive and would cost up to a couple of thousand dollars for each system.

Figure 5.5 SeaKey Box.

5.1.4 Volvo Penta Action Service

Volvo Penta Action Service has operated throughout Europe since 1997. With this service an owner of a Volvo Penta engine has the possibility to obtain help and assistance by phone anytime of the day. The concept of Volvo Penta Action Service is to provide rapid service when customers are in great need. Since many of the incoming calls can be solved by technically competent personal at the call center this is a useful service. When a repair must be performed onboard the operator contacts the closest VP dealer, who can provide the customer with technical assistance or spare parts if necessary. Membership to Volvo Action

21

Service (VAS) is provided automatically to all VP owners and is free during warranty time. Once the warranty period has expired, there is a charge of $50 each successful help action. Volvo Penta Action Service could be a complement to an RVD system, e.g. the Action Service could handle the customer when there is no dealer available for assistance.

5.2 Development

5.2.1 CANSAS-PRO

CANSAS-PRO is developed by Volvo Trucks to help Volvo engineers for development purposes. CANSAS-PRO uses satellite and GSM communication to be accessible all around the world. The intelligence in this system is located in the mobile platform.

Figure 5.6 CANSAS PRO Mobile platform.

The reason why CANSAS PRO is an unsuitable choice for our RVD system is because of its complexity and its expensive hardware. The system is not developed to meet the requirements of the aftermarket. CANSAS-PRO is expensive and much of the logic and functions are unnecessary for RVD purpose in the leisure-boat segment.

5.3 Conclusions

The initial project purpose was to make a market research to find existing RVD systems. The research resulted in us finding commercial system for RVD purpose that aim either at R&D or systems developed to satisfy the needs from the customer point of view. The CANSAS-PRO system is a downright RVD system. Its R&D purpose, with completely different economic demands, makes it way too expensive and complicated for aftermarket use. The customer directed systems provide the car or boat owner with safety services, navigation, entertainment etc. and are optional when a customer buys a vehicle or boat. We find it important not to include RVD systems in an already existing commercial system. The reason is that it would be possible for a customer to relinquish installation in a procured vessel due to lack of interest in the commercial-services aspect. Our ambition after the initial research is to completely isolate an RVD system. By doing that, new system requirements arise. To use the system as a special tool to simplify diagnostic work make cost and functionality to important factors. The system must be coast effective and easy to use for the end customer. The progress in wireless technology makes it possible to find a cost-effective unit with simply the purpose to send engine data from the EVC system to a remote location. In chapter 6 a wireless solution for a mobile unit is presented and in chapter 9 we show and compare the cost and ideas of different telematic solutions. The conclusions from this chapter gave us a higher layer of the initial purpose and a new approach to the problem.

22

Figure 5.7 Levels of purposes with the new higher purpose of Remote access to ECU

data

23

6 TELEMATIC SOLUTIONS This chapter presents different technical solutions which can enable communication between the EVC system and a remote application. The problem was to find a solution which enables communication between the CAN-bus and a remote application, i.e. a mobile unit. This implementation must be as cost-effective and reliable as possible in the leisure-boat environment which has vibrations and damp. In collaboration with VP personnel, an idea of using a Bluetooth link between the CAN-bus and a commercial cellular phone which allows further communication with a remote server, were brought out. In this chapter we give a short overview of this system and in the chapter conclusions we declare what we believe is the most suitable solution, according to our research and investigations.

6.1 CAN to Bluetooth

This chapter explains how a Bluetooth link can be used in a remote diagnostic system and how it can enable access to all ECUs. Bluetooth is a relatively inexpensive communication method where developments of low-price circuits are in progress. The basis of our idea is as mentioned earlier to communicate between the CAN-bus and a commercial cellular phone located at the boat, via a Bluetooth link. The best way regarding to the possibility for future development and high transfer rates is to use a third-generation (3G) cellular phone. The Bluetooth connection should be usable for every commercial cellular phone on the market equipped with a Bluetooth service. Modern cellular phones have no problem sending wanted information, such as DTCs and vital information from the engine. Our first task is to find a reliable and low-price circuit. Next task will be to develop a cellular-phone software application that communicates with a remote user application. This application could be either a web site or a PC application. We were looking for a gateway that could receive CAN packets from the CAN-bus, encapsulate these packets into L2CAP layer of the Bluetooth and then transmit to the Bluetooth network. The Bluetooth-enabled cellular phone should capture these packets. After a reverse encapsulation, CAN packets should be handed over to the application. During research concerning Bluetooth-to-CAN solutions, we contacted Teleca Systems AB, who is developing a product in our interest. Teleca have developed a gateway called Teleca Wireless Automotive Gateway (TWAG). The TWAG gateway makes it possible to fetch data from the CAN-bus and send it via Bluetooth. The mobile device connects to the TWAG by Bluetooth and communicates over Internet via GPRS to a web server. The web server has database access. Further, a client application can reach the database and other services through the web server. The mobile device communicates with the back-end system using other functions on the same web service. To handle different protocols based on CAN, e.g. On Board Diagnostics 2nd Generation (OBD2) and D2, separate modules exist. These modules are used to decode and interpret the result when a request is made, e.g. an OBD2 request. Another module function is to hide specific protocol parts, e.g. handling of flow control and timing.

24

6.1.1 System picture

We give an overview of the system picture of a Bluetooth remote diagnostic system, including a CAN -to-Bluetooth gateway, remote server and a database server.

Figure 6.1 System overview

Today’s diagnosis use J1587/J1708 to request required information from the CAN-bus. Since future prospects of diagnosis are reading directly from the CAN-bus our study focuses on CAN communication only. The CAN-to-Bluetooth gateway is connected to CAN/J1939 and sends information from the boat through a commercial 3G cellular phone to a remote server. The remote server is furthering the information to a database server where all information is stored and made available for future use.

6.2 Result

6.2.1 Bluetooth

The usage of Bluetooth entails problems concerning connection security and availability. Bluetooth connectivity is not always trustable and can be affected when phones get out of range or if improper materials block the unit. A solution is to have a firm place for the phone, near the Bluetooth station. A low-price gateway can be constructed by using a Bluetooth connection between the CAN-bus and an advanced mobile phone which can perform the necessary logic and connection to the back-end system through the Internet. One problem would be to convert the CAN-bus signals via Bluetooth to a cellular phone and make them understandable for the phone and the website. There are two ways to send the information. One way is to send it in its original form and convert it to understandable information at the website. Another alternative is to have data converted by the phone software or in the Bluetooth sender before it is forwarded to the web. Benefits of the last alternative are that information can be readable on the phone and there will also be less data traffic when selection of required data is made before transferring. A benefit of using Bluetooth is the communication standard. All cellular phones have the same Bluetooth connection which makes it possible for all phones equipped with a Bluetooth link to communicate with the boat.

25

Cellular phone using Wireless Application Protocol (WAP) or 3G can easily download software and make phone updates.

6.3 Conclusion

Since development of a CAN-to-Bluetooth gateway already was in progress at Telica with expertise in the field, we decided it was unnecessary to do the same work. Instead, the idea was to collaborate with Teleca. We initiated negotiations with Teleca about how we could evaluate a client interface for possible VP usage. The client could either be a stand-alone client application or a browser. After some discussion concerning application usage and requirements a final proposal came up to us. We began to realize where the core problem was. We defined the core problem as how an RVD system should be used by the actors in a diagnosis and repair process. Due to this realization the thesis changed focus one more time. The plan was to understand how diagnostic work takes place today with the purpose of finding the needs for all actors involved in repair work. An RVD system aims at simplifying the diagnostic work

Figure 6.2 Levels of purposes with the new higher purpose of Increase the efficiency in

diagnostic work

26

7 METHOD FOR REMOTE DIAGNOSTICS This chapter gives a method proposal based on facts from literature studies and input from interviews and consultations. The purpose of the work presented here is to find a suitable method for RVD of an engine in a marine leisure boat. After previous research the main question finally was discernible: How can remote access to DTCs, parameter log and ECU data increase the efficiency in

service and repair work?

Research concerning RVD is mostly concentrated to the technical aspects such as security and connectivity, and is not performed from the actual actors point of view i.e. local technician, central experts and customers [5]. The following questions intend to identify the overall needs from the active participants in the diagnostic work and are answered in the chapter conclusion. Our ambition is to develop an idea or concept of how an RVD system should be designed to increase efficiency in the diagnostic work.

1. What kind of need will an RVD system satisfy for Dealers?

2. What kind of need will an RVD system satisfy for Volvo Penta?

3. What kind of need will an RVD system satisfy for boat owners (End customers)?

4. What are important factors to make the organization (dealers, customers) use the

system?

5. What is relevant information to access when using an RVD system?

6. What is the least expensive implementation?

7. How can the RVD system be introduced to the aftermarket?

7.1 Diagnostic work today

Service and repair of marine engines take place in workshops or boatyards, where the local technician, the engine and in some cases the customer are present. The diagnostic phase always starts by the local technician interviewing the customer to get the customers experience of the problem. From this data the technician can get a first picture of a possible cause of the problem. During the further diagnostic work the dialog often continues, with the purpose of getting a more specific picture of the problem. The technician uses his knowledge to relate the symptoms experienced by the customer to a possible problem cause.

27

Figure 7.1 Collaboration between participants of repair work [6].

In some cases the cause cannot be found. These more complex problems, often related to unrecognized problems with new engine models, are forwarded to central experts at Customer Support (CS) at Volvo Penta headquarter. First, the Market Unit (MU) takes on the case. If they do not have a solution, the case is sent on to the Global Service Development (GSD) for further support. In many cases a central expert has to travel to the spot for assistance. If many cases similar in nature occur, Quality Action Center (QAC) becomes involved to find a permanent solution for the specific problem. This work is made in collaboration with Product Development (PU). PU evaluates the changes and confirms that the new solution is reliable. The overall diagnostic work is carried out through a large amount of collaboration between involved actors.

Figure 7.2 Collaboration between involved actors in Volvo Penta Organization

The central actor in this chain of collaboration is the local technician. He has a central role in the diagnostic work and collaborates with the costumer, MU and CS, se fig 7.1 and 7.2. In field studies with the purpose of discerning how marine diagnostic work of today can be improved by using remote diagnostic previous research revealed important details about how the actors involved collaborate in the repair work. Three main aspects of these were: the importance of being co-located with each other and the boat, the importance of collaboration, and the reliance on local knowledge i.e. knowledge about the customers driving style, the customers knowledge about boats, the reliability of the customers reports, previous problems with a particular boat etc [5].

7.1.1 Remote collaboration

The revealed important aspects of collaboration in diagnostic work today are the following: 1. Co-located with each other and the boat

2. The importance of collaboration

28

3. The reliance on local knowledge

We agree with the thought of using RVD to improve the collaboration of actors involved in diagnostic work. To follow the decentralized concept with the local technician in focus is a suitable approach because of his central role and the importance of his contribution in diagnostic work. This concept is the opposite of the so-called centralized approach adopt by many vehicle manufacturer that advocate the central expert as a central unit. The thought of the centralized concept is that the central expert will take over much of the technician’s role in workshops. Earlier work [5], confirmed by our interviews, indicates that a central expert does not have the local knowledge the local technician possesses. In the end it is the local technician that makes the repair. To first send the information to the central expert and then forward this information to the local technician is a waste of time and a source of misunderstandings. The idea that an engine can be repaired remotely is not going to be reality in a long time. The decentralized way to introduce RVD is to keep the three main aspects of diagnostic work and to improve collaborations between the percipients. When RVD is introduced the methods may be gradually advanced to a more centralized concept as a consequence of developments in the methods and technique. To increase the collaboration an RVD system cerates possibilities in the following ways:

• Remote Access to Diagnostic Data • Remote Collaboration with Customers • Remote Collaboration with the Central Expert

Remote Access to Diagnostic Data

Interviews indicate that 90% of all boat owners have no experience of engines or electronics what so ever and are completely hand out in situations of a failure. It is hard for the local technician to get any information that is useful by oral remote conversation with the boat owner. To enable remote access to diagnostic data for the local technician by e.g. a PC- application, figure 8.1 or PDA, can improve the efficiency in the repair progress. The local technician can get a picture of the problem and prepare his work without physical contact with the boat. The technician can also have benefits when he receives automatically sent DTCs from a boat. He can then contact the customer and ask for his experience of the problem. In this way major engine breakdowns can be prevented. The argument for why the local technician should get the information is his local knowledge. The local technician knows what the customer needs. He is more like a salesman who wants to satisfy the customer. The central expert does not have the same focus. The central expert is more into taking care of the technical aspect of the engine e.g. the customer having problem at startups when the engine is cold. The central expert increases the fuel injection and the engine starts easily. What the customer now experiences is a higher fuel consumption that not is desired. Remote Collaboration with Customers

According to previous work [5] the possibilities for collaboration with the customer remotely would be beneficial. The idea of sending information from boat to local technician’s cell phone or PDA when a new DTC is set in the engine is not an appreciated function. Technicians do not want too much information in the hand unit (PDA or cell phone). Often they are busy working and do not have time to evaluate large amounts of data. They think the

29

most important feature is to have the DTCs stored in an accessible database. They think it is best like it is today when the customer calls the technician when he/she has problem so they can discuss the problem. Instead the technicians like the idea of be able to ask the customer to press the Diagnostic Transfer button. Now the technician gets access to the DTCs in the database, and can see all boat-specific data by use of a web portal. Technicians mean that the boat-specific data e.g. engine model, special spare parts, gear etc. together with DTCs is very valuable information. A common opinion by technicians is that an RVD system would be especially important to customers with no knowledge about engines at all. They do not know anything about the engine or engine model and this requires a trip to the spot to make this clear to the technician. To reduce these trips can be very beneficial. Another case from previous research could be when a customer is about to go for a long trip shortly. The technician knows this and can remotely make sure that certain parameters do not indicate that a DTC is about to be set in the boat. If so, it is sensible to contact the customer to discuss the issue [5]. The local technicians are skeptic to services like that. Our interviews indicate that the local technicians are very busy every day during boat season and most of their days include service work with other customers. To be interrupted with services like this would make the ongoing work inefficient. Remote Collaboration with the Central Expert

New engine models often get problems that are unfamiliar to the local technician due to lack of experience and information. When this happens today the local technician tries to solve the problem sometimes without success. If not successful he explains the situation by e-mail or discussions with central experts. It is very important to get the right information in this mail. Depending on the professional experience of the local technician, i.e. the composer of the mail, the information relevance can vary. Often there are misunderstandings, and the central expert has to travel to the spot to get the required information. To send the DTCs together with specific engine data is the perfect solution for this problem. The central expert knows exactly what kind of engine they are talking about and it is easier to give the local technician a direct answer without travel.

7.2 Conclusion

1. What kind of need will an RVD-system satisfy for Dealers?

There is no problem in finding a technical solution for transferring data like DTCs and other parameters from the EVC system to a remotely located computer. The main problem is the system models and how a model should be designed to increase the efficiency in the service and repair work. The obvious need is to perform the first diagnosis remotely and spare the first trip to the spot just to accomplish a first diagnosis. The technician can get a picture of the problem based on the DTCs and parameters he requests via the RVD system. He can be well prepared with the right tools and a plan for how to solve the problem when arriving at spot. In [1] we can identify other benefits based on interviews with local technicians. A mentioned benefit is the technician’s possibilities to follow up engines with problems. An RVD system that automatically sends DTCs when they occur makes this possible. If a technician can be alerted when a certain DTC occurs at a specific engine make the boat owner comfortable and

30

some problems with new engine models, which the local technician does not have knowledge of, could also be more easily identified using an RVD system. 2. What kind of need will a RVD-system satisfy for End Consumer?

When a boat owner uses his leisure boat it is in most cases for recreational use. Often the boat is used in afternoons, weekends or holidays. In these cases it is in the customer’s highest interest that the boat really works properly at these times i.e. the uptime of the engine is very important. When a leisure boat has an average run hour of 50 h/year it is understandable that the owner does not want any engine downtime at all. For the customer the purpose of an RVD system is mainly to maximize the uptime. An RVD system could reduce the downtime during boat season by improving the collaboration between the customer and the local technician and in that way make the repair work more effective. In some cases DTCs are generated by some one-time incident when a certain value gets outside a predefined scope in the EVC system. In these situations one can reset the DTC by turning of the voltage to the EVC system. Instead of waiting for a busy technician to arrive at the spot and perform this procedure, the customer sends the DTCs to the technician and with his guidance the customer can solve the problem himself. In these cases an RVD system can save days of downtime and frustration. According to the interviews, the feeling of safety is important to the customer. An RVD system can satisfy this need when the customer knows that he/she always have access to professional help by pressing a Diagnostic Transfer button.

3. What kind of need will an RVD system satisfy for VP?

In our research to find an RVD system we established contact to Jonas Kuschel, PhD student at the IT-university of Gothenburg. His research field is similar to ours and he helped us a lot during our research. Based on his work we reject the idea of a centralized approach to the problem. The centralized idea concerns a vision of letting the RVD replace the service technicians in the workshops. The diagnostic work of today is in fact all about collaboration between the actors involved, i.e. the customer, the local technicians and the central experts. In studies it is clearly documented that none of these actors can solve the problems by his own. Based on studies [8], we do not think the centralized idea will be realized, at least not in the near future, simply because the local technician seems to play such an important role in the diagnostic work. The need from VP point of view is not to save money by reducing the number of local technicians with a RVD system but to reduce travels made by local technicians and central experts. In the future the system may well be used for remote upgrades and parameter settings all without travel. 4. What are important factors to make the organization (dealers, customers) use the

system?

An important factor for the customer to use the system is, at first that is worth the money invested in the system. Second, it must be easy to use. To convince those customers to use an RVD system requires simplicity i.e. easy to use, not more than one single button to press if needed. Otherwise something can easily go wrong. If the customer has to go through a complicated procedure to send the information he/she will feel unsure if he/she can remember this in a situation. A feeling of not be able to realize an action like this make the customer doubtful about the whole system. Third, the feeling of security is very important. When customer knows that he/she can transfer all DTCs from the boat to the technician without having any knowledge at all of the boat it is a good feeling for the customer. The only thing

31

the customer has to care about after buying the boat is to use it. He/She does not have to worry about giving a lot of information about the boat if a failure occurs; just press a button and the technician has all technical information he needs. An important factor to have the technicians use the system is of course that it makes the work more effective, and second, low price for the RVD system. According to the interviews we found out that every dealer was very skeptic to the system when the question of cost was mentioned. They do not want to pay anything for the system. Local technicians see this idea as one more electronic system that causes a lot of problems, they do not see the system as a help in their daily work. If the technician in some way can be convinced of the advantage of using an RVD system and observant of that it really works the doubtful thoughts will disappear. 5. What is relevant information to access when using an RVD system?

According to information from our interviews, technicians do not want too much information in the hand unit (PDA or cell phone). Often they are busy working and do not have time to evaluate large amounts of data. They think the most important is to have the DTCs stored in an accessible database. The idea is that the customer calls up the technician when he/she has problem similar to today’s cause of action. They discuss the problem and the local technician asks the customer to press the Diagnostic Transfer button. Now the technician gets access to the DTCs in the database, and can se all boat specific data. Technicians mean that the boat specific data e.g. engine model, special spare parts, gear etc. together with DTCs is very valuable information. The technicians mean that an RVD system would be especially important to customer with no knowledge about engines at all. They do not know anything about the engine or engine model and this require a trip to the spot to make this clear to the technician. To reduce these trips can be very beneficial. 6. What is the least expensive implementation?

We have come to a conclusion about a least expensive system. Based on the fact that everything that adds to the production cost of an engine e.g. hardware associated to an RVD system becomes exceedingly more expensive to the end customer, we had to come up with some idea that requires minimum implementation to production. Our idea is to carry out as much hardware and software as possible from the engine. By connecting a Bluetooth (BT) stack to the diagnose connection or directly to the CAN-bus we minimize the addition of parts. The BT stack has to be initiate only once to be able to forward information from the EVC system to a cell phone placed at the dashboard or somewhere nearby. The cell phone has the software to forward the data via GPRS to Internet and the database. The benefit of this system is that the cell phone is re-programmable with software updates. There is no need to change anything at the boat, only the software in the cell phone. This can be done by downloading the new files by the GSM network or by connecting the phone to a computer and downloading the files. The cell phone is also replaceable i.e. there is no restriction to a special brand or model, the only demands are enough of memory capacity, GPRS and Bluetooth connection. We can se that the least expensive solution is to use techniques used by the public that are well established. To implement a cell phone already known by many customers is both reliable and inexpensive in comparison to other built-in systems. 7. How can the RVD system be introduced to the aftermarket?

This problem has its origin in the lack of interest when the market does not see any use for an RVD service. The prices for similar systems are high. If there would be something more cost-

32

effective and easy to use there would be a market. This would lead to more effective repairs. The aftermarket is the major time of the engine lifetime, and the sale of spare parts is a large part of a manufacturer income. To bind the customers to VP and create a genuine relationship is a tremendous win. A key factor for aftermarket introduction is to make the changes in steps and on a small scale. Most of the local technicians think it is best like it is today why the introduction most not be radical. In some way they have to be convinced that the system stands for improvement of parts of their work. Our suggestion is to give the system to local technicians that are interested in the service and recompensate them in some way. They can be some kind of “super” dealers with special benefits from VP. In this way the system can be tested, evaluated and further developed. In this way hopefully other dealers will have their eyes opened for the system.

33

8 REMOTE-DIAGNOSTIC EXAMPLES The first part of this chapter presents the system design developed according to results of chapter 5, 6 and 7. We present the overall system design and also four different models of short-range communication between the CAN bus and a Bluetooth cell phone. The later part present a scenario of today followed by five scenarios were our model for RVD is applied. The scenarios are worked out in discussions with our supervisor and personnel at VP and describe situations that have high frequency of occurrence today. The scenario objectives are to show how the system satisfies the needs presented in previous chapters i.e. increase the efficiency in diagnostic work. It is central to reduce travels of central experts and local technicians and also the satisfy needs from customers and the other part of the organization.

8.1 System Design

The system design comprises four separate parts; Remote Agent, Remote Server, Database Server and the Internet/PC Application.

Figure 8.1 System design with the Remote Agent (1), Remote Server (2), Database

Server (3) and the Internet/PC application (4).

The Remote Agent (1) is the interface between the boat and the rest of the system. The driver of the boat can initiate the diagnostic by pressing a button to send diagnostic data. The Remote Agent consists of a CAN-to-BT gateway and a Bluetooth-equipped cellular phone. The cellular phone receives data from the CAN-BT gateway and forwards the same data to the Remote Server (2) via GSM/GPRS. The Remote Server (2) acts like a middleware between the Internet/PC Application (4) and the Database Server (3) and also between the Internet/PC Application and the Remote Agent. The Remote Sever contains the system intelligence. The remote server’s task is to translate the data and forward it to the intended place. The Internet/PC Application is the user interface from the other side of the system, used by local technicians or central experts. The user of the application can receive information from the boat and can also make requests of parameters if needed. The diagnostic can be initiated from both ends i.e. from the Remote Agent or the Internet/PC application.

34

8.2 CAN-BT Gateway implementation

This chapter presents the best models of implementation of a CAN-BT gateway on a VP leisure boat engine. The models have been developed in collaboration with personnel at VP and focus on low implementation cost and few additional devices. Model 1 Bluetooth dongle connected on the Sync cable.

Figure 8.2 Bluetooth dongle connected on the Sync cable.

• Access to both drive lines (both Chassi ID) (+). • Hard to access (-).

Model 2 Bluetooth dongle connected to PCU-Engine cable CAN communication.

Figure 8.3 Bluetooth dongle connected to PCU-Engine cable CAN communication.

• Access to one drive line only (-) • Easy access (+)

Model 3 Bluetooth dongle connected to diagnostic connector J1587 communication.

35

Figure 8.4 Bluetooth dongle connected to diagnostic connector J1587 communication.

• Access to one drive line only (-) • Easy access (+)

Model 4

VODIA connected to diagnostic connector, Bluetooth to mobile phone.

Figure 8.5 VODIA connected to diagnostic connector, Bluetooth to mobile phone.

• Access to one drive line only(-) • Easy access (+)

8.3 Scenarios

Scenario 1 - Diagnostic today

Boat X is located close to the home marina. A VP dealer workshop Y is located in connection to the marina. The owner of boat X uses to engage workshop Y for service and repair work. Boat X generates a DTC that is indicated at the instrument panel. The driver of the boat, often the owner, contacts the local technician at Y. The diagnostic work starts with the local technician communicating orally with the customer to find out the experienced problem from

36

the customer point of view. Next step is to get in contact with the boat. This is done either by visiting the boat or by bringing the boat to the workshop. Now the technician connects a VODIA and gets access to the engine data. Data evaluation together with his local knowledge gives the technician a picture of the problem and an idea of the cause. The diagnostic work continues by finding the cause, correcting it, and repairing the engine to a satisfying recovery.

Scenario 2 - Remote Diagnostic, Customer Initiate, close to marina

Boat X is located close to the home marina. A VP dealer workshop Y is located in connection to the marina. The owner of boat X uses to engage workshop Y for service and repair work.

Figure 8.6 Scenario picture with boat close to home marina

Boat X generates a DTC that is indicated at the instrument panel. The driver of the boat, often the owner, contacts the local technician at Y. The local technician gets oral information about the experienced problem from the customer. He then asks the customer to press the Diagnostic Transfer button. The data from the boat, such as DTCs and EVC data, is now transferred and stored in a file related to boat X. The technician can log on to the web application and access the database. The information concerning boat X, together with new DTCs, give the technician a first picture of the problem. If needed the technician can request parameters and perform real-time checks of the engine to investigate the problem even more. After evaluation of the technical data together with the technician’s local knowledge a large step in the diagnostic work is completed i.e. “what” the problem is, and hopefully an idea of the “cause” without any travels. In cases where problems cannot be solved by remote conversation and guidance from the local technician a service appointment can be made. From now the diagnostic work continues as usual with the technician either visiting the boat or bringing the boat to the workshop. When it is time for the repair work appointment, often some time has passed. The customer normally has forgotten details from the incident, information that is important for the local technician for faster and more effective work. Now all information concerning the specific serial number is stored in databases available for later work and is also available if more problems appear concerning the same boat, not necessarily solved by the same service technician. Scenario 3 - Remote Diagnostic, Customer Initiate, far from marina

Boat X is used during holiday and is located far from the home marina. A VP dealer workshop Y is located in connection to the home marina. The owner of boat X uses to engage workshop Y for service and repair work.

37

Figure 8.7 Scenario picture when boat owner is located far from marina

Boat X generates a DTC that is indicated on the instrument panel. The driver of the boat, contacts the local technician at Y or Volvo Penta Action Center. The local technician/Action Center gets oral information about the experienced problem from the customer. The operator then asks the customer to press the Diagnostic Transfer button and to wait for further information about what dealer to choose for the repair work. If the local technician is contacted he can find the nearest dealer in the area and have an opportunity to explain the situation and also give the nearest dealer the chassi-ID for the boat. The data from the boat such as DTCs and EVC-data is now transferred and stored in a file related to boat X. The nearest local technician can now log on to the web application and access the database. He finds the boat by the received chassi-ID. The information concerning the boat X, together with new DTCs give the technician a first picture of the problem. If needed the technician can request parameters and perform real time check of the engine to investigate the problem even more. After data evaluation a large part of the diagnostic work is done without travel, i.e. an idea of “what” the problem is, and hopefully an idea of the “cause”. From now the diagnostic work continues as usual where the technician either visiting the boat or bringing the boat to the workshop. When it is time for the repair work appointment, often some time has passed. The customer normally has forgotten details from the incident, information that is important for the local technician for working faster and more effective. Now all information concerning the specific serial number are stored in databases available for later work and is also available if more problems appears concerning the same boat, not necessarily solved by the same service technician. Scenario 4 – dealer far from water, no boatyard

A VP dealer workshop Y is located far from water and has neither a boatyard nor any facilities for keeping boats in the workshop. The owner of boat X usually engages Y for boat service and repair work. Boat X generates a DTC that is indicated at the instrument panel. The driver of the boat contacts the local technician at Y. The diagnostic work starts with the local technician communicating orally with the customer to find out about the experienced problem from the customer point of view. The technician then asks the customer to press the Diagnostic Transfer button. The data from the boat such as DTCs and EVC data is now transferred and stored in a file related to boat X. The technician can now log on to the web application and access the database. The information concerning boat X, together with new DTCs give the technician a first picture of the problem. If needed the technician can request parameters and perform real-time checks of the engine to investigate the problem further. By evaluation of data together with local knowledge from the technician a major part of the diagnostic work is done i.e. ideas of “what” the problem is and hopefully an idea of the “cause” without travel. If the problem can not be solved by remote conversation and guidance from the local technician a service appointment can be made.

38

Scenario 5 - Remote Diagnostic, Initiate by local technician

Workshop Y has made a service on Boat X. The local technician is interested in the engine behavior after the service. In collaboration with the customer the local technician make real-time checks of the engine when it is operating in its natural environment. The local technician requests the relevant parameters from his office by an internet application and the parameters are displayed in real-time at the screen. Scenario 6 - Remote Diagnostic, Initiate by Central expert Workshop Y is making a service on Boat X. The local technician has a problem finding the cause of the problem. The local technician contacts the central expert and explains the situation. The central expert logs in at the Internet application from his office computer. The central expert has deep technical knowledge about the engine and he also gets access to all necessary information. The central expert request necessary parameters remotely and can now support the local technician.

8.4 Benefits

The actors in the diagnostic work e.g. local technician, central expert and customer clearly benefit by using an RVD system.

8.4.1 Boat owner/Customer

The key factors for the boat owner in the scenarios is maximized engine uptime and also the increased safety and the feeling of been taken care of. By improving safety and reliability in the boat, that is by knowing that professional help is only a button away, the boat owner can enjoy his boat usage to maximum.

8.4.2 Local Technician/Dealer

The dealer’s benefits in scenarios 1 to 5 are, in first hand, lower travel costs, but also less waste of valuable time when the first diagnosis can be made remotely. The possibility to access information such as DTCs and engine parameters, give the local technician a chance to prepare and maybe repair the engine at the first appointment. Secondly, the possibility for a specific dealer to bind a customer. When the local technician saves data related to a boat and its owner in his database he has a chance to improve the business relationship by provide more and better services. He has possibilities to follow up engines in a better way when all specific data are stored in a map related to a specific engine.

8.4.3 Central Expert

The central experts get more detailed background data. With a database with information about the specific boat decrease the chance of misunderstandings in the collaboration between the actors in the diagnostic work. The central expert can give more complete advices without

39

traveling to spot. This is especially usable with new engine models. There is also possible to make statistics of all kind of engine history.

8.5 Further RVD scenarios

Further examples are meant to give a picture of how an RVD system could work in a daily usage of diagnostic and repair work. When a boat builder signs a business contract to use VP engines in their boats they expect quality. When they find an engine problem close to deadline and shipping they are in greatest need of professional help from VP to be able to deliver a quality boat on appointed time. Otherwise, the problem can lead to claims or in worst case a notice of cancellation of the contract. The possibility of qualified service in short time is also a main issue to decrease downtimes for end customers. People or companies who invest in an exclusive boat have big demands on usage whenever he/she wants to. If a problem occurs there must be help available in a short matter of time. Downtime for workboats can in most cases mean a huge loss of income for the owner. With other words, the buyers of a VP engine are in great need of fast and qualified support if a problem occurs. In England Volvo Penta have contract with four major boat builders, which use new VP engines controlled by EVC-systems in their boats. Volvo Penta U.K headquarter is placed in London. A typical critical situation can be as follows. The boat builder company is just about to finish up a new build boat. The buyer wants the yacht to be shipped to his dock in the Mediterranean. A truck is going to load the yacht in four days from this time. Suddenly, the engine in the boat does not start. The boat builder company contacts Volvo Penta Europe and explains the situation to a central expert. The central expert asks the boat builder to connect his transfer device e.g. cell phone, and wait for further contact after the data is transferred. The Volvo Penta personnel can now display the history of the boat including DTCs, problems with related action, EVC software and parameter settings. After evaluation VP personnel can come up with a solution for the problems. With information from the database for the specific boat a problem can be easier to detect and will lead to a faster solution for the problem. When the Volvo Penta technical engineer has the picture clear to him he contacts the boat builder and gives him his opinion. Hopefully the problem is easy to correct and can be made by the builder himself, otherwise an action can be planned in a simple and creative way. Another typical critical situation can be as following example. The boat builder company is just about to finish up a boat for delivery. When the engine test-drive is made a problem occurs. A boat builder representative contacts the closest VP dealer and explains the situation. The dealer has to interrupt his work and try to get as much information as possible by phone to make a preliminary diagnose. He takes his service devices and drives the 100 km to the site, connects his Vodia and initiates diagnostic of the engine. After a data evaluation he realizes the problem to be an injection sensor indicate an error (but the real problem is a blockage in a hose connection which brings out the sensor error). Without improvement after sensor replacement, The VP dealer contacts the VP U.K Market Unit and explains the situation. The Market Unit gets in contact with the Customer Support (CS) and the Global Service Development (GSD). GSD is responsible for the technical support and warranty matters. GSD gets the information and sends a VP technician to solve the problem. The technician is the third part in the information flow, which means that important information can be lost. The technician has about 400 km traveling one way. That means 800 km two

40

ways plus overnight costs, and he maybe finds something more that needs to be replaced or corrected that results in an even longer delay.

Another example where RVD could be useful is when a train due to start up its 20 brand new engines and they do not start. Volvo Penta sends a technician to find the problem at a cost of 20 000 Swedish crowns for traveling and 5000 for accommodation. When the technician arrives he realizes the problem is that the engines are out of fuel. When the tanks are filled up the engines start up perfectly. This scenario could be avoided if the technician had used a remote diagnostic tool to find out that the fuel tank was empty and contacted the personal on place to fuel up.

41

9 MARKETING Marketing research can be used to evaluate the acceptability of a product or a service and to find out its worth. RVD could have the potential to improve results by e.g. reducing cost, gaining efficiencies, customizing service and attracting and retaining customers. Loyal customers lead to increased revenues and also result in cost savings for warranty, and provide a source for product quality improvement. To market an RVD system, underlying decisions need to be made about what the purposes are for an RVD system at VP.

9.1 Economy measure

9.1.1 Cost of implementation

This chapter does not include a full economic analysis. We give a short overview of an approximated cost of implementation for a number of telematic systems considered in chapter 5 and 6. Hardware cost/unit SeaKey 2 000 $ CANSAS PRO 4 000 $ CAN/Bluetooth 100 $ GSM modem 150 $ Cost of implementation involves prices for communication parts i.e. telematic hardware and not the surrounding accessories e.g. signal processing, sensors, instrument and other surrounding equipments.

9.1.2 Cost saving

The introduction of an RVD system will in first hand reduce travel costs. However, interviews with dealers and local technicians indicate that deficient information may lead to the necessity of being present at spot and performing supplementary diagnostic anyway. That fact can lead to lower travel avoidance than predicted. However, the overall opinion among dealers is that RVD usage in daily work will simplify and speed up lot of work with remotely located customers.

9.2 Solution details

This section discusses aspects of changes related to system implementation. Changes would include:

• Changes to organization, personnel, training, etc.

42

• Changes to processes.

• Changes to surrounding systems.

The ambitions when implementing RVD are not to change any supporting systems but would be a simplifying complement for existing systems. We believe VP needs a RVD expert since further development and continuously follow up are necessary. By discussions with dealers and VP personnel we confirmed that giving training and experience in remote diagnostics for technician and personnel would neither take much time nor be a costly process. The reason why we believe the training of local technicians would not be a costly process is because it is in their own interest to undertake RVD to simplify their work. Something that we not further investigate in this report is the development in VPPN for making RVD services available at the web-portal including databases, servers and other data communication equipments.

9.3 Risk Management

In the near future experts forecast a legalization of all actors to produce and sell RVD systems for readout of engine data. This will be a natural result of an anti-trust law that allows all actors to have access to manufactures engine data. A standard protocol will be set and all engine manufactures have to follow it. Customer demands for the product are obvious and it will be the supplier of the best product that will have the most profit. A large number of telematic manufactures will enter the market and they will concentrate at the RVD only, and fast have advantage. The manufacture that offers the best product will be the market leader.

Figure 9.1 VP engine equipped with Telematic Box with standardized interface

Since VP´s core business is making engines at good standard they will not have a change against producers with RVD as core business. A better solution would be to concentrate on what to do with the information. All data which been taken out would be stored in a database belonging to VP. This eliminate the data out take since once the information is stored at a central database the information is accessible for every authorized person. A database like this could be a tremendous source for a lot of participant. The database could then be described as a “virtual engine”, with data stored from all outtakes that have been done. Within the organization there would be a whole new way to follow up the engines and get all kind of information for specific engines. There will be a market value in the database, i.e. all kind of

43

statistic, engine and market related data could be taken out for a cash-and-carry price. Different kinds of licenses or applications for specific purpose can be sold.

Figure 9.2 Engine data stored in a virtual vehicle by using RVD

In this case a leading telematic manufacture holds his position. VP still has a small part at the market, but the benefit of selling licenses will be the argument [14].

9.4 Volvo Penta Head Quarter

QAC – Quality Action Center GSD – Global Service Development SAM&I – Sales, Application, Marin & Industry

9.5 Business Emission

Market Unit - MU

International United States Asia Europe

Dealers Dealers Dealers Dealers

Customer Support - CS

QAC - Quality - Project

GSD - Technical support - Warranty

SAM&I - Installation

Training - Education

44

"Volvo Penta supplies technically advanced engines and power systems to demanding customers in selected marine and industrial segments. Our product and service offering is designed in the spirit of customer orientation and Volvo’s core values – quality, safety and environmental care. Our products and services shall generate competitive advantages for our customers and provide end users with superior reliability and performance. Our business operations shall contribute to an increased volume base and profitability for the industrial operations of the Volvo Group. We work with energy, passion, and respect for the individual."

9.6 Conclusions

The main factor is not the economic profit made by supplying the market with RVD systems. The profit is in providing new service possibilities and in giving the customer a feeling of being taken care of. The service also creates possibilities for better and faster services by reducing travels. Since safety and reliability is hard to translate into cost and savings, the importance of using an RVD system is hard to bring forth in the economic analysis. A few issues are still to be unresolved, e.g. whether the services will appeal to the customer or whether the customer will pay for the services. RVD services are not likely to be an income for VP by providing the market with RVD systems, but benefit will be in improvement of quality and service without larger expenses.

45

10 FUTURE WORK The telematic market has high expectations and desires for Remote diagnostic systems [4]. As we mentioned before, the technique is available for developing of a systems that meet our requirements. We have brought out certain future applications. To make progress of these services a gradually development of prototypes by trail and error principle should be made. This is a way to find systems with lasting functions. To continue investigation and getting closer to a complete product questions like cost of implementation and development comparing to economically profit must be answered.

10.1 Future Applications

An RVD system could enable following useful applications:

• Log Vessel Data (LVD) • Sea trials • Engine tests • SoftWare DownLoad (SWDL)

Regular readings of engine data saved in a database are a good information source for evaluation and development purposes. Before a boat is delivered to a customer, a procedure called Sea trials is performed where the engine is checked to make sure everything works properly. Sea trails could be progressed with an RVD system by making a check after the boat have settled away from the dealer. By including RVD systems at Sea trial, warranties cost could greatly be reduced by eliminate unseen mistakes that lead to future warranties. Today SWDL is illegal, but in a future with better communication possibilities and regulations an SWDL service could be very useful to reduce travels for work that could be performed remotely.

10.2 Future visions

Our future vision of a perfect RVD system is an automatic diagnose system for all VP engines giving technicians direct instructions of current problem without involvement of personal judging. A future RVD system could also be used for preventive measuring to avoid future failure. This could dramatically change diagnostic works and problem solving concerning engine systems. The system could compare current problem with earlier repair works and making a proposal for preventive repairs.

46

11 CONCLUSIONS

Volvo Penta´s purpose is to sell top class marine engines with high quality. To improve business there is always an effort to satisfying customer needs as well as improving customer loyalty by making services more efficient. A good way to increase service and quality is to make progress in RVD development and become first ahead in marine engine industry to enable RVD. We suggest that RVD should be offered as an important part of a safety and security package and by that increase engine values aiming at the Volvo core values; quality, safety and environmental care. To improve customer loyalty it is important to listen to the customers and find out what they believe is important factors. An important outcome of our investigation is that customers would decline paying for an RVD service, especially in the early stage development when the service would be invisible to the customer. Another reason why payment liability should be separated from the customer is that dealers do not always have the possibility to use the service, e.g., where dealer does not has the technology available or if the dealer is not skilled enough to use the system. An unreliable service cannot be sold to a customer. That limitation could be avoided with a well developed and widely spread system which offers the necessary security and stability that customers want. The importance of customer loyalty and the fact that customers will decline paying for an RVD system gave us economical and functional requirements for the technical aspect. The system must be as cheap and reliable as possible and also easy to use. The initial research purpose did not seem very complicated: The goal was to find a suitable, already existing RVD system for implementation on a VP boat engine. When we tried to find system within our requirements we discovered that no suitable system exists. The existing systems were all developed for other purposes than the one we had in mind i.e., they focus either on satisfying customer needs or on advanced engine diagnostic for R&D. These segments have complete different economical demands than our system which aiming the aftermarket. We argue that the GSM network of today is a suitable communication link for our system design. GSM communication is preferable over satellite communication because there is often a need for oral communication between local technicians and customers during the repair work. Another reason is that it is a cheaper way to communicate, both when is comes to equipment and to data traffic. Our experience from this work is that a problem often has more than one side. This important understanding made us consider what the purpose of our project really was. A major task was to find the right purpose and arrive at a research question. Finally we identified the highest level of purpose as; Increase the efficiency in diagnostic work. The study was then refocused to the daily work of diagnostic instead of searching for existing RVD systems. By doing that we could formulate research questions with the purpose to find needs from the participants in diagnostic work. To find an answer for these questions we could not only take the technical aspects into consideration. Even if a remote diagnostic system is faultless in a technical way it would not fulfill its purpose unless it is design to fit in the diagnostic work as it takes place today. The performance and local knowledge possessed by the local technicians have been the base for our investigation. We have listened to dealers’ ideas, thoughts and reflections on the potential benefits of RVD systems. We have understood that the most important factor for retaining customers is customer satisfaction. The introduction of an RVD system that leads to faster services, reduced engine down time and increased customer awareness can lead to larger available customer groups. We believe that a customer who feels taken care of and who at the same time is a participant in the repair work feels more comfortable.

47

The results present a way for the participants to collaborate remotely instead of being present at the same geographical location, se figure 7.1, by adopt daily techniques. Due to the many participants there were many different needs to consider in order satisfying all parties. In chapter 7 we identify the needs from the most important participants and have this in consideration when the final system design is presented in chapter 8. The most important result of our work is the success of finding the right purpose that was totally unknown from the beginning. We successively understood more why there is no RVD system at the market today that is designed for remote diagnostic. Most of the previous research in field of remote diagnostic is in high grade focused on the technical aspects of wireless communication. We realized this is the major problem. The problem lay in a whole other dimension. The first step is to make clear how the diagnostic work taking place today. In our research we found out the process of diagnostic work and identified factors that could be improved in order to simplify work. Everything in diagnostic work is about collaboration between the participants. We found it would be very hard to introduce a system that is perfect in a technical way when the needs from the intended users are not yet identified. Next important step was to make a profound investigation to find needs from all participants in the diagnostic process that also is intended users i.e. local technicians, central experts, customers and also other part of organization such as R&D. A result of this work was that we found a solution that took those needs in consideration and result in a system that not is permanently attached to the engine. The system does not require a lot of changes but can simply be attach to the EVC system without lots of additional coasts in fabrication. The idea of bring out as much as possible of the system from the boat and use well known and establish technique is a success. By this we found a solution fitting economical requirements and the use of well established techniques made the system user friendly. Another approach that was in consideration was the cost aspect. Initial goal of this project was to make a business plan which we did not accomplish. Why a business plan is exclude from the report is the difficulty to make an entirely costs analysis of such a wide scope. The work finally results in an idea of how to get the system out on the market and use its entire potential, see appendix 1. The launch should be made in three steps, beginning by providing a selected number of dealers with the RVD system. Demands for those dealers are both interest in the new system and that they are located in areas where the benefits can be obvious. The importance of interest is critical, otherwise serious feedback is hard to get and system development will slow down. As repay the chosen “super dealers” could get advantages and extra support. A perfect place is Spain, where the VP headquarters is located in Madrid, far from coast. This contributes to long distance travels for central experts when problems occur by the coastline. By using the system VP takes advantage of special in-house competence with reduced travels as result. Second step will be to use even more of the system potential by save information about engine problems in a database accessible from client connected to VPPN. Central experts can by international collaboration find solutions for different problems. Third will be done by improve local activity i.e. improve the dealer-customer service. The dealer will provide his customers with RVD systems and make his own customers network. When system and procedure has been brought to maturity it will hopefully result in increasing efficiency in diagnostic work by making a joint venture where collaboration between all participants in diagnostic work is the core issue.

48

11.1 Vision

Our vision of a future RVD system is centered in the VP organization with an installation of an RVD system in every leisure boat equipped with a VP engine. In a future vision, with more developed services and better contracts for claims of several reporting systems (basic check or claim report), required payment could be an income for VP. Future usage of RVD is meant to be working in combination with VPPN cause of dealers’ familiarity to VPPN information and service web portal. An ambition is to give product developers the ability to use a system application as a tool for comparing engines or to implement other useful features. The tool can search for engines from the same production year, location, working hours etc. and compare performance or display other wanted information. This information leads to better support and investigation possibilities of marine engines. An application for upgrade engine software remotely is technically possible with an RVD system. An application like this could be used for correcting software bugs by releasing software upgrade campaigns. Remote software upgrades make it possible to install new software wherever the engine is settled e.g. in power generators located in remote places or in rough environments where it is hard to reach the engine. A reason to install an RVD system could be to increase the value of a boat. We believe an introduction of RVD to VP engine systems will reduce the number of unpleased customer at the sellers. These customers will instead make contact directly to a dealer or the action service. This will be a benefit for the seller, by making them less involved with problem solving and instead more concerned about selling. The software structure should similar Vodia software, combined with the already known VPPN network web-portal. By that it is possible to reduce outlay for software constructions and upgrades. As we mentioned earlier the main factor for satisfying a customer is to increase safety and reliability in boat performance. A loyal customer leads to increased revenues for VP. We believe the only way to make a customer willing to pay for an RVD service is to make him feel safe and well taken care of. To make a customer safe, a future RVD system needs to be reliable.

49

12 References

1. Marttala, A., Karlsson, Å. et al, Projektboken: Metod och Styrning för Lyckade Projekt, Studentlitteratur, Lund 1999

2. Backman, A. et al, Rapporter och uppsatser, Studentlitteratur, Lund 1998 3. Hamilton. K. (2002). Practical Self-diagnosing AUVs, SeeByte Ltd. 4. Allied Business Intelligence, The Digital Car “Dynamic Player Roles and Business Models

in the Telematics Value Chain", May 2002. 5. Kuschel, J., Ljungberg, F. et al, Decentralized Remote Diagnostics: A Study of Diagnostics

in the Marine Industry, Application Development Group, Department of Applied IT, Box 8718, 40275 Göteborg, Sweden. (s28,29,30,31)

6. Kuschel, J. et al, Blue-Collar Ubicomp in the Vehicle Industry, Application Development

Group, Department of Applied IT, Box 8718, 40275 Göteborg(s28) 7. Global telematics, http://www.global-telematics.com (s6) 8. Nationalencyklopedin, http://www.nationalencyklopedin.se(s6) 9. http://nweb.waymaker.se/bitonline/2001/09/10/20010910BIT00330/09100033.htm(s20) 10. VOLVO ON CALL, OnCall

http://www.volvocars.co.uk/VolvoOwnership/OnCall/About.htm(s21) 11. How it works, SeaKey

http://www.volvo.com/volvopenta/na/en-us/partsservice/customer_care/seakey(s22) 12. Remote Diagnostics, Networkcar a Raynold and Raynold Company

http://www.networkcar.com/networkcar/pub/remotediagnostics(s7) 13. Frost & Sullivan's Analysis Of The European Remote Vehicle Diagnostics Market http://www.frost.com

12.1 Personal references

14. Jonas Kuschel, IT University, Gothenburg, 0707-141510

1

Appendix 1

2

3

4