Arduino needs an external software —executed in a PC— to write programs in the development board. This latter is an open source programming language and IDE based in Java; generally used as a medium to teach multimedia and interactive digital design projects. The program will execute immediately within it. This function is the core of all Arduino program and it is the one performing most of the load. Figure 2. We chose this board because the electric interface to control the CAN bus previously described is designed for total compatibility with Arduino UNO, i.
This is documented in the corresponding library. CAN is one of the most employed bus communication protocols due to its relatively long reach, communication speed, and high reliability. It is commonly implemented in control machines and in automotive diagnostics buses. Figure 3. There are other alternatives to implement the CAN bus, such as the case of the Sparkfun CAN expansion, but it is not completely compatible with Arduino UNO; a modification in the libraries to establish communication between both devices is required.
It is a representation of an ECU with connected sensors and electric circuits emulating parameters such as speed, acceleration, and others room temperature and engine coolant temperature.
Figure 4 describes this subsystem in a general way. Figure 4. ECU simulator. Parameters such as speed, acceleration, position of the gas pedal, several temperature values, MIL state, fuel level, and statistics related to failures in the engine, among others, can be measured. Two data trouble codes have been programmed following the requirements of the OBD message structure to reply a request in mode Additionally, we added an LED to simulate the MIL indicator of the vehicle board —which is activated when a failure is detected—.
This action of detecting a failure is triggered by pressing a button implemented and connected to the interruption 1 of the Arduino UNO. This mode erases the trouble codes and generates a positive response message for the operation mode 04 if the deletion was successful. The system was developed in an Arduino Mega board Figure 5 and its corresponding expansion card, providing CAN connectivity and allowing the connection with CAN networks. Figure 5.
We have programmed it to comply with the initial objectives in the OBD-II standard, such as real-time parameters measurement, trouble codes related with failures in the vehicle, and ability to delete the data in the computer once the maintenance in the vehicle solved the issues "CanOBD The scanning software is in charge of making requests through the CAN bus and through the Arduino expansion board handling that data bus. The main program implements the following functionalities:.
The CAN data bus inside the vehicle has multiple interconnected modules, each one of them is represented by an address or ID. Immediately after the scanner is plugged in and it starts receiving data, we perceived that many messages with different IDs to the expected ones arrived.
For that reason, we decided to apply the message filtering and masking in these functions to ensure the reception of diagnostics messages only. Table 4 presents an example of the message ID filtering and masking operation method inside the CAN communications protocol. Table 4.
Filtering and masking of CAN messages. Once the messages are received, it processes them and returns the information to the PC to get a broader visualization. The requests are made considering the received data. For instance, if the received command has the ID of the main window in the graphical interface, then an OBD-II message is built to survey the related parameters with the indicators in that window, except the DTC deleting requests.
These latter have a different command, since they are only user-triggered. Figure 6 shows the set up function flow. OBD2 can also be compared to other higher layer protocols e. J , CANopen. However, if you're inspecting an older car pre , it is useful to know the other four protocols that have been used as basis for OBD2.
Note also the pinouts, which can be used to determine which protocol may be used in your car. The standard describes both the vehicle OBD2 connector and the connector used by the external test equipment e. In particular, the standard dictates the location and access to the OBD2 connector. SAE J : The J standard describes the data protocol used for heavy-duty vehicle communication. In today's world of connected cars, OBD2 tests can seem cumbersome: Manually doing emission control checks is time-consuming and expensive.
Basically, OBD3 adds a small radio transponder as in e. This saves cost and is convenient, but it is also politically a challenge due to surveillance concerns. However, the German car industry is looking to change this :.
OBD has been designed to service cars in repair shops. In no way has it been intended to allow third parties to build a form of data-driven economy on the access through this interface ". The proposal is to "turn off" the OBD2 functionality while driving - and instead collect the data in a central server. This would effectively put the manufacturers in control of the automotive 'big data'. The argumentation is based in security e.
Whether this becomes a real trend is to be seen - but it may truly disrupt the market for OBD2 3rd party services. In principle it is simple to log the raw CAN frames from your car. If you e. Car hackers may try to reverse engineer the rules, though this can be difficult.
CAN is, however, still the only method to get "full access" to your car data - while OBD2 only provides access to a limited subset of data. For details, see our OBD2 data logger guide. In simplified terms, an OBD2 message is comprised of an identifier and data. Note that 7E8 will typically be where the main engine or ECU responds at. Length: This simply reflects the length in number of bytes of the remaining data 03 to For the Vehicle Speed example, it is 02 for the request since only 01 and 0D follow , while for the response it is 03 as both 41, 0D and 32 follow.
Mode: For requests, this will be between A. I am trying to understand the CAN protocol for reading the diagnostic information from a car. I am using a Vector GL logger, and I am writing the code for this. The GL uses a C-like language, and for me to retrieve information it uses the following format:.
And for example if I wanted to retrieve the engine coolant temperature, the PID is: I understand my variable will look like so:. I know this is far fetched, but Vectors IT cannot help me. Is there a way I can clarify such a far fetched question? UDS is a closed standard, but essential parts of it are available online.
However, reality is usually harder than that: many ECUs will require you to send a Diagnostic Session Control request first, or even reply to Security Access challenge. Others will require a checksum to be present in the last data byte.
You may have to experiment quite a bit to get this working on the ECU you have at hand. There is no really easy anwer to that. In the case you are actually trying to do standard ISO OBD, given that 7E0 and 7E8 are actually the standard addressed, the best way is to read the ISO specifications they are expensive but you can find most of the stuff online.
You should start with ISO and follow the leads. There are many tutorials around with many info. On-board diagnostics, OBD2 is a 'higher layer protocol' think of it as a language while CAN bus is a method for communication like a telephone. Basic pids can be found on Wikipedia, which contains a complete set of basic commands that all cars should support.
There are also sets of commands for certain brands and types of cars, these sets are available for a fee. Sign up to join this community.
0コメント