Search Results

SAE J1979 and its “OBD Modes” served for the protection of our environment against harmful pollutants for decades, but due to regulatory adoption of Unified Diagnostic Services (UDS), SAE J1979 has now become a multiple part document series: SAE J1979 will be replaced by SAE J1979-2 for vehicles with combustion engines (ICEs) and by SAE J1979-3 for Zero Emission Vehicle (ZEV) propulsion systems. For ZEVs, emission-related failures will be replaced by ZEV propulsion-related failures. Both SAE J1979-2 and -3 are variants of ISO 14229 (UDS) but limited to emission-related and ZEV propulsion-related failures, respectively, and associated diagnostic data. These new diagnostic communication protocols are required by California Air Resources Board (CARB) but do not support vehicle-manufacturer-specific diagnostic applications like calibration or flash programming.

Vehicle manufacturers and their suppliers are legally mandated to develop low-emission engine technologies. Type approval for road-vehicles or non-road mobile machines is only granted when the limits for carbon monoxide (CO), nitrogen oxides (NOx), hydrocarbons (HC), and particulate matters (PM) are observed. In addition to complying with emission standards, road-vehicles must be equipped with a supervising system (OBD) that monitors emission-related components and detects and indicate divergences from admissible pollutant limits. As of today, emission control systems are required for non-road mobile machinery, but not their monitoring by an OBD system. This paper starts with a short introduction to the classical OBD system. For more than three decades, OBD serves as an essential part of the environmental protection.

This paper describes a system and a process to significantly decrease the downtime of commercial vehicles that are immobilized for the purpose of Inspection and Maintenance (I/M) in the workshop. The process is based on a data acquisition system that is installed in the vehicles and collects data from a fleet under real driving conditions. The collected data is sent to the cloud and merged with other data sources, such as diagnostic data requested from the vehicles in the workshop, history data, test drive data, and so on. The target-oriented analysis of selected data items results in predictive maintenance sequences. The sequences are described in OTX [1] and downloaded to the workshop tester that processes OTX sequences. In combination with Qtr.-based GUIs, the service technician is guided thru the maintenance process. If required, an external technical expert can access the vehicle remotely and support the local service technician to do his job right the first time.

This paper will provide an Overview of Automotive Cyber Security Standards related to the Vehicle OBD-II Data Link. The OBD-II Connector Attack Tree is described with respect to the SAE J3138 requirements for Intrusive vs. non-Intrusive Services. A proposed test method for SAE J3138 is described including hardware and software scripting. Finally, example test results are reviewed and compared with a potential threat boundary.

The increasing complexity of microcontroller-based automotive E/E systems that control road-vehicles and non-road mobile machinery comes with increased self-diagnosis functions and diagnosability via external test equipment (diagnostic tester). Technicians in the development, production and service depend on diagnostic test equipment that is connected to the E/E system and performs diagnostic communication. Examples of use cases of diagnostic communication include but are not limited to condition monitoring, data acquisition, (guided) fault finding and flash programming. More and more functions of a modern vehicle are realized by software (firmware). Powerful multicore servers replace the numerous control units and many control unit functions can be performed directly by smart sensors and actuators. New E/E system architectures come with increased self-diagnostic capabilities.

In the near future, vehicles will operate autonomously and communicate with their environment. This communication includes Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I) communication, and comunication with cloud-based servers (V2C). To improve the resilience of remote diagnostic communication between a vehicle and external test equipment against cyberattacks, it is imperative to understand and analyze the functionality and vulnerability of each communication system component, including the wired and wireless communication channels. This paper serves as a continuation of the SAE Journal publication on measures to prevent unauthorized access to the in-vehicle E/E system [9], explains the components of a cyber-physical system (CPS) for remote diagnostic communication, analyzes their vulnerability against cyberattacks and explains measures to improve the resiliance.

Diagnostic Communication with Road-Vehicles and Non-Road Mobile Machinery examines the communication between a diagnostic tester and E/E systems of road-vehicles and non-road mobile machinery such as agricultural machines and construction equipment. The title also contains the description of E/E systems (control units and in-vehicle networks), the communication protocols (e.g. OBD, J1939 and UDS on CAN / IP), and a glimpse into the near future covering remote, cloud-based diagnostics and cybersecurity threats.

Today’s road-vehicles (passenger cars, LDV, MDV and HD commercial vehicles), as well as non-road mobile machinery (NRMM), are equipped with E/E systems that consist of electronic control units, in-vehicle networks, sensors, actors, wiring, connectors, and some electrical and electrohydraulic components. Coping with the increasing complexity of these systems requires a new approach for external test equipment being deployed in the entire process chain: development with verification & validation for SOP, manufacturing/production, and after-sales service. Numerous papers are dealing with the technology of external test equipment, (remote) diagnostics, troubleshooting, guided fault finding, predictive maintenance and the standardized components, such as UDS, MVCI, ODX, and OTX. Diagnostic sequences are described in OTX and processed by an OTX runtime module. The OTX runtime module uses the MVCI D-Server API, and the D-Server processes diagnostic data which is described in ODX.

Remote diagnostic systems support diagnostic communication by having the capability of sending diagnostic request services to a vehicle and receiving diagnostic response services from a vehicle. These diagnostic services are specified in diagnostic protocols, such as SAE J1979, SAE J1939 or ISO 14229 (UDS). For the purpose of diagnostic communication, the tester needs access to the electronic control units as communication partners. Physically, the diagnostic tester gets access to the entire vehicle´s E/E system, which consists of connectors, wiring, the in-vehicle network (e.g. CAN), the electronic control units, sensors, and actuators. Any connection of external test equipment and the E/E system of a vehicle poses a security vulnerability. The combination can be used for malicious intrusion and manipulation.

Remote diagnostic systems support diagnostic communication by having the capability of sending diagnostic request services to a vehicle and receiving diagnostic response services from a vehicle. These diagnostic services are specified in diagnostic protocols, such as SAE J1979, SAE J1939 or ISO 14229 (UDS). For the purpose of diagnostic communication, the tester needs access to the electronic control units as communication partners. Physically, the diagnostic tester gets access to the entire vehicle´s E/E system, which consists of connectors, wiring, the in-vehicle network (e.g. CAN), the electronic control units, sensors, and actuators. Any connection of external test equipment and the E/E system of a vehicle poses a security vulnerability. The combination can be used for malicious intrusion and manipulation.

Passenger cars are equipped with an OBD connector according to SAE J1962 / ISO 15031-3. Passenger cars that support ISO UDS on DoIP use the same connector with Ethernet pins according to ISO/DIS 13400-4 (Ethernet diagnostic connector). If external test equipment is connected to the Ethernet diagnostic connector via a 100BASE-TX cable with the RJ45 connector at the tester, a VCI is not necessary anymore. With a device that fits the Ethernet diagnostic connector physically and acts as a converter between the Ethernet signals and WLAN, external test equipment that supports wireless communication, can be connected to the vehicle. Examples for such wireless external test equipment include Android/iOS- based smart phones and tablets with purpose-made applications (APPs). The software components of external test equipment are standardized in ISO 22900 (MVCI). The MVCI D-Server processes data in ODX (ISO 22901) and sequences in OTX (ISO 13209).

SAE J1939 is the synonym for a CAN-based in-vehicle network for heavy-duty road-vehicles (trucks and buses) and non-road mobile machinery (NRMM). The SAE J1939 standards collection consists of 18 parts and 2 digital annexes. SAE J1939-21 (Data Link Layer) describes the data link layer using the CAN protocol with 29-bit identifiers, SAE J1939-73 (Application Layer – Diagnostics) includes the specification of diagnostic messages (DMs). The software components of external test equipment can be described by software interfaces (APIs). ISO 22900 (Modular Vehicle Communication Interface) contains the description of the D-Server that comes with the D-Server API for the diagnostic application and the D-PDU API for the connection to the in-vehicle network (e.g. CAN). ISO 22901-2 (D-PDU API) references SAE J1939-73 and SAE J1939-21 as “Truck and Bus CAN”. D-Server based external test equipment is powered by data which is described in ODX.

In the past, the automotive industry has learned the lesson that competition on the level of bits and bytes, proprietary bus systems, data communication and diagnostic protocols is unrewarding. Too much time and money has been spent on the development of proprietary diagnostic tools. Vehicle manufacturers and suppliers realized that standardization would be the best way to overcome this situation. Furthermore, regulatory requirements in the US and the EU for such standardization have strengthened this lesson. As a result, the automotive industry has standardized the technology for the communication of external test equipment with electronic control units (ECUs) in road vehicles. Standardization serves the price, the quality and the maintainability via scale and training curve effects.