2005-01-1444
An Intelligent Diagnostic System for Distributed, Multi-ECU Automotive Control Systems Thomas Foran and Brendan Jackman Center for Automotive Research, Waterford Institute of Technology, Ireland
Copyright © 2005 SAE International
ABSTRACT A modern automobile is becoming far more complex with the release of each new model. Complexity arises in the form of new mechanical devices, electronic devices and nowadays software components. With this increase in complexity, the job of diagnosing a fault is becoming increasingly difficult, as the service technician now requires detailed knowledge in a range of disciplines. This paper describes an Intelligent Diagnostic System (IDS) that was developed to intelligently diagnose faults in a multi-ECU (Electronic Control Unit) environment. Intelligence is achieved by diagnosing several faults while always attempting to isolate a “core” faulty component instead of simply returning a series of faults.
component B’s ECU. Therefore there are apparently two faults when in fact there is only one fault, causing both components to be replaced when in fact only one component need be replaced. Other scenarios are not as complex as the one outlined above, for example where a component does not affect any other component and is therefore independent and easily diagnosed. All of this information is captured by the Diagnostic FMEA worksheet and subsequently transferred to the model-base either as individual records or as relationship records as discussed later.
AUTOMOTIVE DIAGNOSTIC SYSTEMS NEED FOR DIAGNOSTICS
INTRODUCTION Automotive diagnostics has seen rapid growth in the past. This growth continues with the ever increasing number of electrical components in a typical vehicle. The increase in computerized electronic vehicle systems in today’s automobiles is creating tremendous diagnostic challenges for automotive service technicians [1]. This paper will outline a unique Intelligent Diagnostic System (IDS) that will examine the relationships between different components of an automobile to propose a global fault diagnosis rather than just identifying a series of isolated faults. The Intelligent Diagnostic System will examine the effects that a malfunction of one component may have on the rest of the components in the automobile. The proposed Intelligent Diagnostic System will consist of an intelligent layer that will use MBR (Model Based Reasoning) where the knowledge will be extracted from a FMEA worksheet. The paper will describe the steps involved in modifying the FMEA worksheet to describe “relationships” between components. It will also demonstrate how it can be easily integrated into existing ECUs through industry standard technologies (OSEK) and standards (KWP2000). Diagnosing faults in a multi-ECU environment is a difficult task. Problems arise when a fault in component A may cause component B to register a faulty state in
If a vehicles system/subsystem appeared not working, then every component, sensor and connecting cable of the system would have to be tested. This can be a very time consuming process as a typical Volvo passenger car has almost 1,300 meters of wiring [2]. A single component may cause the entire system failure, but with the introduction of effective diagnostic procedures it would now be possible to provide alternative parameters to enable so called “limp-home” functionality. In order to save service time and inevitably service cost, a service technician must localize a fault as soon as possible. An effective diagnostic system must locate a defective ECU and determine which component of that ECU is at fault, so that it can be replaced as soon as possible. It is estimated that the average European passenger car has an annual down-time of 16 working hours due to malfunctions and maintenance [3]. The figure is even greater for commercial vehicles. This figure means that in Europe alone, a total of over 1 billion hours is spent on diagnosis and repair. In early diagnostic systems, there was only a global error display with an ambiguous warning light available to the driver. However, drivers now require more detailed information about the current state of their automobile along with any procedures that should be followed in the event of system/subsystem failure.
CLASSIFICATION OF AUTOMOTIVE DIAGNOSTICS Vehicle diagnostics categories namely: •
•
can
be
subdivided
into
two
On-board Diagnostics – The objective of on-board diagnostics is to detect abnormality during system operation or detect abnormality during a diagnostic test [4]. These systems have internal embedded diagnostic procedures that get executed. Off-board Diagnostics – This type of diagnostic refers to tools that are typically used in a vehicle repair shop and end-of-assembly line tests where a suitably qualified service technician would connect external tools to perform tests on the vehicle.
On-board diagnostic systems are continuously monitoring the “state” of the vehicle. Elements that are typically monitored for an engine include the catalyst, misfire, fuel system, oxygen sensor and evaporative system [5]. Both on-board and off-board diagnostics have their advantages and disadvantages. One of the main advantages of off-board diagnostics is that there is no extra burden on the ECU to perform diagnostic functions. Also, the experience of the service technician is invaluable and from past experience, an experienced service technician could easily diagnose a fault. However, human expertise can become a very costly asset to keep. Diagnostic systems today are not only capable of detecting a problem, but also isolating the faulty component and determining the severity of the fault detected [4]. Today, more than 50% of code and application data, of a high-end SI-engine ECU are related to on-board diagnostics [6].
FMEA FMEA (Failure Modes and Effects Analysis) has been a well-established practice for design analysis for a number of years [7]. It is a process that makes an attempt to identify problems that may occur in the future with a certain product/process and tries to potentially reduce the number of faults that may occur. In order to capture more diagnostic information from a standard FMEA worksheet, new columns have been added to the FMEA worksheet to produce a Diagnostic FMEA worksheet as shown in Table 2. The columns that have been added to a standard FMEA worksheet to create a Diagnostic FMEA worksheet are: • • •
Node No. Fault Code Corrective Action
The most important addition to the FMEA worksheet is the “Fault Code” column. Each individual potential failure mode that can be identified by a local ECU is given its own Fault Code number. Therefore each Fault Code on
its own will be able to identify a unique fault. In addition to the Fault Code a “Node No.” column is also added which is used to identify the ECU that will report the Fault Code. This means that the same Fault Code can be reported by different ECUs with the Node No. being able to identify which ECU reported the fault. A Corrective Action is also associated with each Failure Mode which is used to describe the procedure to repair the current fault. Diagnosing a fault where there is a 1:1 (1 to 1) relationship between the Potential Failure Mode and the Fault Code is a relatively simple task. As shown in Table 1 below, the Fault Code 001 suggests that there is a fault in the “Power Circuit” where “High Resistance in FL Headlight circuit” is causing “Reduced FL Headlight”. There would then be a unique Fault Code that identifies each individual circuit that supplies power to each light. However, there may be other Failure Modes that might give rise to the “High Resistance in the FL Headlight”. For example, if the battery was low then the Front ECU would report “High Resistance” in each lighting circuit for all of the lights. Therefore the Failure Mode of “Low Battery” will give rise to several Fault Codes. This is an example of a 1:N (1 to many) relationship where one Failure Mode gives rise to many Fault Codes as shown in Table 2. Research has shown how an off-the-shelf model-based reasoning (MBR) expert system was used to diagnose faults in an off-highway vehicle based on the knowledge in a FMEA worksheet [8]. Results showed a reduction of 19 minutes in diagnosis time and accuracy hit rate increase of 30% compared with manual methods.
Power Circuit
High Reduced FL 1 Resistance in Headlight FL Headlight circuit
001
Check local wiring circuit and repair as necessary
6
Wear of wire 2
2
24
High Reduced Resistance in FR FR Headlight Headlight circuit
002
Check local wiring circuit and repair as necessary
6
Wear of wire 2
2
24
1
RPN
Detection
Occurrence
Current Controls
Severity
Potential Cause(s) of Failure
Action Taken
Corrective Action
Responsibility
Fault Codes
Recommende d Action
Node No.
RPN
Potential Effects of Failure
Detection
Potential Failure Mode
Occurrence
Item and Function
Action Results
Severity
FMEA Process
Table 1: FMEA worksheet showing 1:1 relationship
Power Circuit
Power Circuit (contd.)
High Reduced FL 1 Resistance in Headlight FL Headlight circuit
001
Check local wiring circuit and repair as necessary
6
Wear of wire 2
2
24
High Reduced Resistance in FR FR Headlight Headlight circuit
1
002
Check local wiring circuit and repair as necessary
6
Wear of wire 2
2
24
Low Battery Front ECU 1 at Front ECU not 1 operating 1 correctly 1
001
Age of battery 3
2
36
Age of battery 3
2
36
Age of battery 3
2
36
004
Check for clean 6 contacts with 6 battery else replace battery 6 6
Age of battery 3
2
36
1
005
6
Age of battery 3
2
36
002 003
Table 2: FMEA worksheet showing 1:N relationship
RPN
Detection
Occurrence
Current Controls
Severity
Potential Cause(s) of Failure
Action Taken
Corrective Action
Responsibility
Fault Codes
Recommende d Action
Node No.
RPN
Potential Effects of Failure
Detection
Potential Failure Mode
Occurrence
Item and Function
Action Results
Severity
FMEA Process
MBR – MODEL BASED REASONING MBR OVERVIEW The central concept of model-based reasoning is the concept of a “model”. The model is used to represent the components and the connections between components. This model defines the structure and behavior of the system [9]. The target system’s structure can be decomposed into subsystems and components that exhibit certain behavior. As can be seen from this approach, the more detailed that you break a system down into its individual components, the more you will be able to find an exact fault. However, the more components that are to be represented in the model, model complexity will vastly increase. In order to decide the level of detail to identify the components of a system, it is a good idea to identify the least replaceable unit (LRU) in a system or subsystem. A LRU is the smallest unit to which diagnoses needs to be done, because it is the level at which repair is carried out [10]. If the LRU is a subsystem then there is no need to model individual components of the subsystem. Hence there needs to be a compromise on the level of detail and the level of diagnoses required. In a MBR diagnostic system, the set of diagnostic rules is replaced by a model of the target system. The diagnostic problem is to identify discrepancies between the actual model and the predicted model. These discrepancies can then be used to diagnose the problem and the diagnostic task is to find which component or combination of components will result in such a discrepancy. The following are two prevailing approaches to modelbased diagnosis: •
•
Consistency based [10]: In this approach, the system is a set of first-order sentences defining how the systems components are connected and how they normally behave. It does not take into account any abnormal behavior. Abductive [11]: In this approach, the system description contains just different models of behavior and does not distinguish between normal and abnormal behavior.
ADVANTAGES AND DISADVANTAGES OF MBR One of the major benefits to using Model-Based Reasoning is that the models are compositional, thereby allowing the gradual development of model component libraries that can be used at a later stage in the development of other diagnostic systems. The ModelBased Reasoning approach also lends itself to a better explanation facility as the models can be easily used to explain the faulty component. Model-based systems also have their disadvantages in that Model-Based systems and Rule-based systems
require increasing computing hardware to manage scalability. When more rules are added to the system or a model grows in numbers of parameters or complexity, computing performance can be degraded [12]. Model-based Reasoning has been proved to be suitable for diagnosing multiple faulty components [13] where the faulty components are different in nature. Nyberg used MBR for diagnosing both sensor and leakage diagnosis in the air-intake systems of an SI-Engine. Also, model-based approaches have the advantage in that system diagnostics are updated automatically as the model is updated. However, deciding on the granularity of the models can be a challenge. A major decision at design time is to decide what level of diagnostics is required. Model-based reasoning is usually used for well-understood domains that can be accurately represented in a formal language and which tend to be static.
IDS – INTELLIGENT DIAGNOSTIC SYSTEM An Intelligent Diagnostic System was developed based on a MBR module that uses current automotive technology so that it could be easily integrated into any modern vehicle. This was achieved through the use of OSEK (an Operating System used in automotive ECUs), current international diagnostic standards (KWP 2000) and current automotive practices (FMEA), which are all discussed in this section. The IDS tool must have the capability of diagnosing realtime faults in an automotive multi-ECU environment. Therefore the IDS tool will take the form of a diagnostic node on the network. It should be noted that a diagnostic node does not have to be a standalone ECU, instead it may be integrated into an existing ECU with diagnostic sessions being carried out periodically or during low activity on the network. The IDS tool uses an abductive approach to modelbased diagnosis ARCHITECTURE OF THE IDS The IDS tool was developed and run on an IBM compatible PC as a Win32 application. This allowed for greater flexibility and a more comprehensive model-base for the MBR process. However, in order for the IDS tool to run in a Win32 environment the same way in which it can be run in an OSEK environment, the OSEK environment had to be simulated to give a “Virtual OSEK” environment. The diagram shown in Figure 1 below illustrates the software architecture of the IDS tool from a Win32 perspective.
struct model_base_relationship { int Index; int FailureOccurences; int FaultCodeList[50]; int NodeNumbers[50]; int NumberofFaultCodes; char Item[100]; char FailureMode[100]; char FailureEffect[100]; char CorrectiveAction[100]; int Occurrence; } mbrRelation[RELATIONS_SIZE];
Figure 1: IDS Software Architecture
MODEL-BASE STRUCTURE In order to capture the information held in the Diagnostic FMEA worksheet, and use it in the MBR process, two structures were developed to store the information in the form of a model-base: • •
model_base_record model_base_relationship
As can be seen from above, two new fields have been added to the record. Firstly, the FaultCodeList field is used to identify all of the Fault Codes that must be present in order for the FailureMode field to be true. Secondly, the NumberofFaultCodes field is used to hold the number for Fault Codes in the FaultCodeList. MODEL-BASE CREATION To create a model base, a Converter application was developed that took the Diagnostic FMEA worksheet in MS Excel Spreadsheet format as input and then produced the model-base structures fully populated in the form of a C file. This C file was then used as the model-base and was compiled along with the other files in the IDS project. This process is illustrated in Figure 2 below and can be used for any system domain that uses a pre-formatted Diagnostic FMEA worksheet.
The model_base_record holds information about each individual record in the FMEA worksheet as shown in the structure below. The only addition is the use of an Index value which is used as an identifier to uniquely identify a record in the model-base. struct model_base_record { int Index; int FailureOccurences; int FaultCode; int NodeNumber; char Item[100]; char FailureMode[100]; char FailureEffect[100]; char CorrectiveAction[100]; int Occurrence; } modelBase[MODEL_BASE_SIZE];
As mentioned previously, diagnosis is easily performed when one Failure Mode gives rise to only one Fault Code. However, diagnosis becomes complicated when one Fault Code gives rise to many Failure Modes as identified in the FMEA worksheet. In order to capture this information, a model_base_relationship structure was developed to identify instances where more than one Failure Mode is generated by a Fault Code. The structure for a model_base_relationship record is shown below.
Figure 2: Model Base creation process
STRUCTURE OF IDS The IDS tool is run as two OSEK Tasks, namely: • •
DSM – Diagnostic Service Manager MBR – Model Based Reasoning
The MBR Task is started periodically either by another Task or an Alarm. The first job of the MBR Task is to request diagnostic data from the DSM Task, after which the MBR Task will terminate. The MBR Task is then activated again when a response is received from the DSM Task with the complete set of diagnostic data. The MBR Task is then responsible for interpreting the diagnostic data and then compiling a report that may be used either as information for a driver display or to be stored in ECU memory. The DSM Task is responsible for composing and decomposing CAN messages as per the KWP 2000 diagnostic standard. When the MBR Task requests diagnostic data from the DSM Task, the DSM Task will
send out the KWP 2000 CAN messages to each individual ECU and will then set an OSEK Alarm for a specific time. When the alarm has expired, it will read the messages from each message queue and build a response message containing the diagnostic data from each ECU. This response message is then sent back to MBR Task for interpretation. The following diagram shown in Figure 3 below illustrates the software state diagram for the IDS tool from an OSEK perspective.
case MBRresponse: ReceiveMessage( response_from_DSM); Perform_Reasoning_Process; Display/Store results; Update Fault Frequencies; STATE = MBRrequest; break; } }
The reasoning process produces a list of current Fault Codes as well as a list of current Failure Modes. For each Fault Code and Failure Mode a history is then recorded where each time a Failure Mode is recorded the Failure Mode counter for that particular Failure Mode is incremented. The same was carried out for each Fault Code. The Failure Mode frequency was stored in the FailureOccurences field of the model-base record but the Fault Code Frequency is stored in its own structure as shown below. struct DTC_OCCURENCES{ int DTC; int NodeNumber; int NumOccurences; } DTCHistory[DTC_HISTORY_SIZE];
The DSM Task was also developed as a state machine whereby it also carried out tasks depending on what state it was in. The code listing shown below illustrates the pseudo code for the DSM Task.
Figure 3: IDS – OSEK State diagram
The pseudo code for the MBR Task is given below. As can be seen from the pseudo code, the MBR Task was developed as a state machine whereby the task that was carried out depended on the state the MBR Task was in. Task MBRTask{ switch (STATE){ case MBRrequest: SendMessage(request_diagnostic_data_from_DSM); If( message_sent_successfully ) STATE = MBRresponse; break;
Task DSMTask { switch (STATE) { case SendRequest: ReceiveMessage(Message_From_MBR); SendMessage(ReadDTCInformation, ECU1); SendMessage(ReadDTCInformation, ECU2); SendMessage(ReadDTCInformation, ECU3); STATE = ReceiveResponse; SetRelAlarm(x); break; case ReceiveResponse: ReceiveMessage(ReadDTCInformationResp, ECU1); ReceiveMessage(ReadDTCInformationResp, ECU1); ReceiveMessage(ReadDTCInformationResp, ECU1); StoreResponsesInSingleDataBuffer; SendMessage(send_stored_results_to_MBRTask); STATE = SendRequest; break; } }
The DSM Task either requests the Diagnostic Fault Codes or interprets the responses from the ECUs depending on which state it is in. It uses the KWP 2000 service ReadDiagnosticTroubleCodes to gain access to the ECU data. It should be noted that the results returned are only the current Trouble Codes as opposed to any history data.
MBR – THE REASONING PROCESS
TEST RESULTS
The purpose of this section is to describe how the MBR Task performs the reasoning process in order to correctly identify a Failure Mode or a group of Failure Modes. Once a Fault Code or multiple Fault Codes have been identified, the MBR process has to then diagnose the Failure Mode based on the Fault Codes.
The IDS tool was tested using a simulated vehicle lighting system. Although a vehicle lighting system in a vehicle will not take the form used below, it is adequate to prove the principles that this research is based on. The three ECUs are as follows:
The first stage is to identify all Failure Modes that unique Fault Codes give rise to. Secondly, the MBR process must then be able to distinguish between a group of local Failure Modes or global Failure Modes. For example, in the vehicle lighting system that was used as a test bed, Fault Codes 001, 002, 003, 004, 005 all gave rise to individual Failure Modes (i.e. local short circuit). These were stored as unique records in the model-base. However, the presence of all of the Fault Codes 001, 002, 003, 004, 005 gave rise to a single Failure Mode (Low Battery). This was stored as a relationship in the model-base. The reasoning process had to be able to identify which Failure Mode to report. The algorithm used to correctly identify the Failure Mode was based on the hypothesis that if all of the Fault Codes that formed the relationship were present then the likelihood is that the Failure Mode identified by the relationship is the correct Failure Mode particularly if it had greater occurrence rating. The pseudo code shown below illustrates the algorithm used to identify the current Failure Mode(s) based on a single Fault Code or set of Fault Codes.
• • •
Front ECU – control of front lights Back ECU – control of back lights Switch ECU – control of switching mechanism
In order to simulate faults in each of the three ECUs mentioned above a Diagnostic Fault Generator (DFG) was developed that generated the DTCs when requested from the IDS tool as shown in Figure 4 below.
Figure 4: IDS Test environment
The DFG was primarily developed as an application to set a current DTC list for each node on the CAN bus for the vehicle lighting network. The IDS tool was extensively tested including the following Test Cases:
ReceiveMessage (Complete_Set_of_FaultCodes); If (All Fault Codes = 000) OKFlag = 1; If (OKFlag != 1){ Loop through FaultCode list { If (FaultCode corresponds to a single Failure Mode in Model_base) Add Failure Mode to current Failure Mode list Else Add Fault Code to Duplicate List End If } Loop through relationship list { If (FaultCodes in Duplicate List = a relationships FaultCode list) { If (Set of Fault Codes satisfies more than one relationship) { Rank according to occurrence If (occurrences are the same) Rank according to match with most FaultCodes Add Failure mode to current FailureMode list Remove FaultCodes matched from Duplicate list } } } Loop through remainder of Duplicate list { Add individual FailureModes to current FailureMode list } }
• • • • • •
Individual Failure Modes Detect Zero Failure Modes Identify and Prioritize multiple failure modes Identify and Prioritize multiple occurrences multiple Failure Modes Display Historical Failure Modes and DTCs Detect communication failures
of
The IDS tool was able to identify all of the scenarios listed above with 100% success rate. This success rate largely depended on the ability of an ECU to detect faults (ie. Open circuits, short circuits, etc.). However this is common place in modern ECU circuit board design.
CONCLUSION An IDS (Intelligent Diagnostic System) architecture was developed that used CAN, KWP 2000, OSEK, FMEA and MBR to diagnose faults in a multi-ECU environment. The IDS tool was then extensively tested with 100% of faults being diagnosed correctly. The IDS had the capability of diagnosing faults correctly but it depends on an accurate model-base and therefore a comprehensive Diagnostic FMEA process.
This research not only describes a software architecture that is capable of diagnosing faults with 100% accuracy, it also describes a process for capturing diagnostic data that combined with the IDS tool is capable of diagnosing faults accurately across many networked ECUs. This research is unique in that it describes a process for developing and using an Intelligent Diagnostic System that is capable of diagnosing several faults while always attempting to isolate a “core” faulty component instead of simply returning a series of faults. The Intelligent Diagnostic System was developed in a manner that requires almost no additional work to be done in order for the system to be used in any multi-ECU environment. This was achieved through the use OSEK Tasks whereby the Intelligence was built into an OSEK Task and through the use of existing diagnostic standards (KWP2000).
[8]
[9]
[10]
[11]
[12]
[13] One of the most unique aspects of this Intelligent Diagnostic System is the ability to develop a “knowledge base” from existing information - FMEA worksheets that are already well established in the vehicle development lifecycle. The development of the FMEA Converter application enables the transfer of existing information that is gathered from the FMEA process to be used as valuable knowledge in the Intelligent Diagnostic System.
REFERENCES [1]
[2] [3]
[4]
[5]
[6]
[7]
Gray, M, Overcoming the limitations of the System Architecture of On-board vehicle Diagnostics, On and Off-board Diagnostics – PT81, SAE, pp391395, ISBN: 0768006473 Kent, M., Volvo S80 Electrical System of the future, www.tech2.volvo.se, December 1998. Lapetz, J, et al., A Multiplex Communication system for Gaseous Fuel Control with Bi-Fuel Onboard Diagnostics, On and Off-board Diagnostics – PT81, SAE, pp455-459, ISBN: 0768006473 Sachenbacher, M., P. Struss, R. Weber, Advances in Design and Implementation of OBD Functions for Diesel Injection based on a Qualitative Approach to Diagnosis, On and Offboard Diagnostics – PT81, SAE, pp163-172, ISBN: 0768006473 Mischker, K., H. Hillner, J. Schiemann, A New Object-Oriented Diagnostic System Management for Power Control Units with OBD, On and Offboard Diagnostics – PT81, SAE, pp325-338, ISBN: 0768006473 Unger A., J. Albinson, K. Hellgren, J. Schachtschabel, D2 – A Natural Evolution from OBD II, On and Off-board Diagnostics – PT81, SAE, pp403-410, ISBN: 0768006473 Hughes, J, Improving reliability and safety process for wiring harness design, MIRA-New Technology, 2002, p186-188.
Barkai, J, Automatic Generation of a Diagnostic Expert System from Failure Modes and Effects Analysis (FMEA) Information, SAE Technical Paper No.: 1999-01-0060. Davis, R., Diagnostic reasoning based on structure and behaviour, Artificial Intelligence, Vol. 24, pp347-410, 1984. Reiter, R., A theory of diagnosis from firstprinciples, Artificial Intelligence, Vol. 32, pp57-95, 1987. Poole, D., Normality and faults in logic-based diagnosis, Proc. 11th Intl. Joint Conf. on Artificial Intelligence, IJCAI-89. pp1304-1310, Detroit. Morgan Kaufmann, 1989. Grace, H.M., J. Crane, D. Struckman, Lessons for the Auto Industry Learned from Medical Diagnostic Methods Nyberg, M., Model Based Diagnosis of Both Sensor-Faults and Leakage in the Air-Intake Systems of an SI-Engine, On and Off-Board Diagnostics, PT-81
CONTACT Thomas Foran B.Sc. M.Sc. Thomas received his M.Sc. in Intelligent Automotive Diagnostics in 2003 from Waterford Institute of Technology. He is currently working as a Software Engineer in the Airconditioning department at DENSO UK, currently based in Coventry, England. Before joining DENSO, he worked as a Research Assistant at the Center for Automotive Research at Waterford Institute of Technology, Ireland. He has extensive experience in automotive diagnostics and automotive software applications. Email:
[email protected]
Brendan Jackman B.Sc. M.Tech. Brendan is the founder and Director of the Centre for Automotive Research at Waterford Institute of Technology, where he supervises postgraduate students working on automotive software development, diagnostics and vehicle networking research. Brendan also lectures in Automotive Software Development to undergraduates on the B.Sc. in Applied Computing Degree at Waterford Institute of Technology. Brendan has extensive experience in the implementation of real-time control systems, having worked previously with Digital Equipment Corporation, Ireland and Logica BV in The Netherlands. Email:
[email protected]
Website: http://www.wit.ie/car
