can volvo penta master_004_2006

of 60 /60
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

Author: musicjanez

Post on 14-Oct-2014

2.275 views

Category:

Documents


8 download

Embed Size (px)

TRANSCRIPT

Remote Diagnostic System for LeisureBoat EnginesPETER ANDERSSON AND JONAS LINDVALL

Department of Signals and Systems Chalmers University of Technology Gteborg, Sweden, 2006

EX004/2006

PrefaceThis 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 masters 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 wouldnt 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.

ii

SummaryProgress 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.

iii

Table of Contents1 INTRODUCTION........................................................................................................................................ 1 1.1 1.2 1.3 1.4 1.5 2 BACKGROUND ........................................................................................................................................ 1 PURPOSE................................................................................................................................................. 1 LIMITATIONS .......................................................................................................................................... 2 PROBLEM DEFINING ............................................................................................................................... 2 OUTLINE................................................................................................................................................. 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 3.2 LITERATURE STUDIES ............................................................................................................................. 9 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 GMs 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

iv

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 10.1 10.2 11 11.1 12 12.1 FUTURE WORK ................................................................................................................................... 45 FUTURE APPLICATIONS ........................................................................................................................ 45 FUTURE VISIONS ................................................................................................................................... 45 CONCLUSIONS .................................................................................................................................... 46 VISION.................................................................................................................................................. 48 REFERENCES....................................................................................................................................... 49 PERSONAL REFERENCES ....................................................................................................................... 49

v

TerminologyACK: 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 Accessvi

Vodia: Diagnostic software for PocketPC based PDA VP: Volvo Penta WAP: Wireless Application Protocol

vii

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

1.1 BackgroundThis masters 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 worlds 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 engines all ECUs, including drive control levers, control panels and cables, is the vessels 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 GMs OnStar, Volvo OnCall and VPs 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 PurposeA 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].

1

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 LimitationsThe 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 Definition1. 2. 3. 4. What different RVD systems are available at the market? How can an RVD system be implemented in the EVC system? What changes are required from a Volvo Penta point of view? What are the technical requirements for an RVD system to satisfy VP?

1.5 OutlineIn 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 approaches2

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 todays 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.

3

2 FRAME OF REFERENCE2.1 TelematicsThe 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 DiagnosticsDiagnostics 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 technicians instincts of engines behavior to todays computer-controlled engine systems, which need computerized diagnostic tools to make an understandable diagnosis. Problems that can occur with todays 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.

4

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. Todays access of technical information from the boat gets available from the Volvo Penta diagnose tool VODIA. VODIA is a PDA application, developed for Volvo Pentas 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 diagnosticMarine 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

5

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 costeffective 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 vehicles 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 Todays 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, GMs OnStar, Volvo OnCall and VPs 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 customerVPs 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. Research and Development (R&D)

Production

Aftermarket

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

6

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.

7

3 METHODIn 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, VPengine 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

8

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 prestudy 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 studiesAs 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 InterviewsThe 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.

9

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.

10

4 TECHNICAL FRAMEWORKElectronic 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 todays Volvo Penta engine systems for leisure boats, and affect our RVD research.

4.1 Electronic Diesel Control EDCVolvo 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 system11

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 EVCEVC 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 Yconnector 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.

12

Figure 4.2 EVC-system overview.

4.3 Diagnostic Trouble Code DTCWhen 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 128 PID 164 DATA XXX DATA XXX DATA XXX CRC 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 InterfaceToday 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 linkA 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.

13

4.6 Control Area Network CANWhen 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 80s, 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 15bit 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 VPs 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

14

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 CIUThe 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 BluetoothBluetooth 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.15

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 3G3G 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 single16

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 spreadspectrum 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.

17

5 EXISTING SYSTEMSThis 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 Networkcars 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, GMs 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 systems5.1.1 GMs 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 OnStars 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

18

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 GMs OnStar system overview

5.1.2 Volvo OnCall Volvo OnCall is a core part of Volvos 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 RVDsystem solution for a general implementation at VP engines.

Figure 5.3 Volvo OnCall system overview

19

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 Action20

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 Development5.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 ConclusionsThe 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.

21

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

22

6 TELEMATIC SOLUTIONSThis 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 BluetoothThis 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.

23

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 Todays 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 Result6.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.

24

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

6.3 ConclusionSince 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

25

7 METHOD FOR REMOTE DIAGNOSTICSThis 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 todayService 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.

26

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 collaboration27

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 technicians 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 PCapplication, 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 technicians 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

28

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 Conclusion1. 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 technicians 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

29

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 customers 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

30

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 todays 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-

31

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.

32

8 REMOTE-DIAGNOSTIC EXAMPLESThe 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 DesignThe 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 servers 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.

33

8.2 CAN-BT Gateway implementationThis 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.

34

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 ScenariosScenario 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

35

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 technicians local knowledge a large step i