The adaptive platform of the Autosar consortium forms the basis for high-performance computers (HPC) in vehicles. It integrates support for multiprocessor systems, parallel processing with dynamic configuration management for resources and updates, and service-oriented communication (SOC). High-performance computers present new and exciting challenges for vehicle diagnostics. OnBoard and OffBoard diagnostics have to keep pace with the gradually increasing complexity of software in vehicles and their environment. The current trend in diagnostic software is to transfer the diagnostic functionalities to the vehicle.
At first glance, adaptive Autosar does not mean any great changes for a diagnostic tester. A D-PDU API will have an additional protocol module for Diagnostics over IP (DoIP) to enable communication with an Adaptive Autosar. The UDS and ISO specifications will also be extended to include some new features.
Standardisation in ISO will be completed by the end of 2019. As the standardisation process has focused on evolution and extensive compatibility, there are no radical changes that would require a new system design in diagnostics. These changes are expected to be incorporated into existing off-the-shelf diagnostic tools during the course of 2020.
During DoIP, the vehicle to be diagnosed is first selected on the basis of the vehicle identification number (VIN) and communication is then established with the individual control units via their diagnostic addresses. One of the challenges here is that an adaptive control unit can have several diagnostic addresses at the same time, with one diagnostic address per software cluster (SWC) along with the associated Diagnostic Manager. An adaptive control unit will then typically have 5 to 10 software clusters and so will have the same number of diagnostic addresses.
The above example gives two (diagnostic) applications for ECAS. The first is for lowering a vehicle to make it easier for passengers to board (so-called kneeling) and the second is a tilt function to prevent a bus from rolling over. These two applications do not have to be simultaneously active in the software cluster "ECAS". They can be started and stopped dynamically during operation as required.
Depending on the vehicle variant, applications can also be switched on or switched off completely. For instance, in the above example, a "Lane Change Assistant" is a chargeable feature and is either permanently deactivated or is only activated additionally during the course of the vehicle's service life.
Applications with diagnostic functions will therefore no longer be available simultaneously or may even be permanently deactivated in the vehicle. A tester must therefore be familiar with and able to manage the relevant vehicle data using the VIN. He can no longer assume that all DTC information in the Diagnostic Manager of a control unit is current or available.
Both software clusters, each of which has its own diagnostic address, also require two ODX data pools.
In principle, a control unit with Classic Autosar is an analogue for a software cluster in Adaptive Autosar. The Autosar environment automatically ensures the distribution of diagnostic requests to the respective Diagnostics Managers of a software cluster.
On the whole, however, these changes represent more of an evolution than a revolution.
It becomes more interesting when the new possibilities of an OnBoard Diagnostic Tester are taken into consideration in conjunction with an extended diagnostic functionality in the vehicle.
At present, an electrical component diagnosis is common in Classic Autosar. Here, the connected hardware is checked cyclically for errors and any errors found are stored in the Diagnostics Management. The error reaction defined by the error of a component during creation of the effects analysis, i.e., the Failure Mode and Effects Analysis (FMEA), is triggered by the error event.
For example, in the case of a "Stuck at High" error, the opening of a low-side driver to enable an actuator that is incorrectly and permanently connected to be switched to a second independent path. The electrical problem is hereby conclusively tackled at the component level first and, as a result, one switching function and at least one actuator fails.
The failure of an actuator will inevitably have an effect on the system into which it is integrated. In order to ensure that these effects are taken into account correctly, Autosar is equipped with the concept of events that can be used to inform other applications about changes that have occurred. The failure of this switching function would result, for example, in the "Lower lift axle" function of a commercial vehicle no longer being available at system level. The affected function will then also receive a corresponding error code at this level.
The effects on the system, ECAS in our example, are taken into account in the system-FMEA and further follow-up actions are triggered by event. In our ECAS-example, this would result in the function "Raise functional lift axle" being blocked in order to avoid a reduction in the permissible vehicle load capacity due to the raising of the lift axle, which is still technically possible.
The failure of the "lift axle" system function has different effects on the vehicle. If the current lift axle remains lowered, this affects only the system properties and leads to a decrease in the ease of steering, increased fuel consumption, and wear on the tyres.
In the case of the failure of a raised lift axle, the available payload is reduced, which would have a significant impact on the availability of the vehicle and may necessitate on-road service of the vehicle to reduce the load.
An Onboard Diagnostic Tester collects the incoming error events here via DoIP, then makes decisions on how to proceed with the situation, and is of course available for further analyses in the case of on-road or off-road services. During this process, the OnBoard Tester can access not only original UDS diagnostic information, but as an Adaptive Autosar application, it can also actively access other interfaces from other applications via the ARA::COM interface for in-depth analyses.
The amount of data to be analysed and the mutual dependencies between the control units and their applications in the development of control units are increasing, which makes diagnostic development more complex. The classic separation between the development of control units and (after-sales) diagnostic development must therefore be eliminated in the future to enable more effective and efficient developments in this area.
The E/E development process starts with the requirements to be met by a vehicle, including the planned variability. The state of the art in this case is to import the specification data of a requirements management system into a vehicle data editor. The architecture of the control units is further specified in this vehicle data editor and the communication requirements (conventional: a "CAN matrix") are defined. Modern tools allow both the Autosar data (DEXT) and the diagnostic data (ODX) to be specified together at the same time and to be managed in a common database.
There is a large area of overlap between the contents of these two data formats, for example, in the case of DTC and DID. However, both formats contain all the necessary information for the development of control units. In the case of DTCs, ODX lacks approximately 40 attributes that describe a DTC in the control unit, such as the priority of the error and the debouncing strategy to be used.
In order to enable a developer to work effectively and efficiently when adding or modifying a DTC, it is almost vital that he should create and manage definitions only in one place for this purpose. Once a tool has all the necessary information, DEXT and ODX data can be generated from it, and, if changes are made later, these are also reimported and exported back into the respective other format.
This ensures coherence of the ODX and DEXT data, meaning that a function developer needs only one tool for his daily work. The changes are reflected in both areas at the touch of a button.
This process enables the creation of all necessary data formats for development and after-sales. In addition, test sequences can be generated automatically to verify the actual diagnostic behaviour of the control units.
This brings effective diagnostic options directly into the vehicle in conjunction with the various diagnostic layers, i.e., Component, System and Vehicle, of an Adaptive Autosar control unit. Trouble-free operation and a high level of reliability are thereby ensured to the greatest possible extent. In the case of errors, prompt diagnosis adapted to the vehicle variant is provided.
Thanks to intelligent problem management, complex functions such as ADAS can retain their best possible range of functions even if a subsystem malfunctions.
Diagnostics therefore retains the necessary prerequisite for adapting to the ever-increasing requirements of complex autonomous systems of the future. Diagnostic testers will be integrated into vehicles having high-performance computers with sufficient resources for these testers. This will make diagnostics more comprehensive and mobile!
At first glance, adaptive Autosar does not mean any great changes for a diagnostic tester. A D-PDU API will have an additional protocol module for Diagnostics over IP (DoIP) to enable communication with an Adaptive Autosar. The UDS and ISO specifications will also be extended to include some new features.
Standardisation in ISO will be completed by the end of 2019. As the standardisation process has focused on evolution and extensive compatibility, there are no radical changes that would require a new system design in diagnostics. These changes are expected to be incorporated into existing off-the-shelf diagnostic tools during the course of 2020.
During DoIP, the vehicle to be diagnosed is first selected on the basis of the vehicle identification number (VIN) and communication is then established with the individual control units via their diagnostic addresses. One of the challenges here is that an adaptive control unit can have several diagnostic addresses at the same time, with one diagnostic address per software cluster (SWC) along with the associated Diagnostic Manager. An adaptive control unit will then typically have 5 to 10 software clusters and so will have the same number of diagnostic addresses.
The above example gives two (diagnostic) applications for ECAS. The first is for lowering a vehicle to make it easier for passengers to board (so-called kneeling) and the second is a tilt function to prevent a bus from rolling over. These two applications do not have to be simultaneously active in the software cluster "ECAS". They can be started and stopped dynamically during operation as required.
Depending on the vehicle variant, applications can also be switched on or switched off completely. For instance, in the above example, a "Lane Change Assistant" is a chargeable feature and is either permanently deactivated or is only activated additionally during the course of the vehicle's service life.
Applications with diagnostic functions will therefore no longer be available simultaneously or may even be permanently deactivated in the vehicle. A tester must therefore be familiar with and able to manage the relevant vehicle data using the VIN. He can no longer assume that all DTC information in the Diagnostic Manager of a control unit is current or available.
Both software clusters, each of which has its own diagnostic address, also require two ODX data pools.
In principle, a control unit with Classic Autosar is an analogue for a software cluster in Adaptive Autosar. The Autosar environment automatically ensures the distribution of diagnostic requests to the respective Diagnostics Managers of a software cluster.
On the whole, however, these changes represent more of an evolution than a revolution.
It becomes more interesting when the new possibilities of an OnBoard Diagnostic Tester are taken into consideration in conjunction with an extended diagnostic functionality in the vehicle.
At present, an electrical component diagnosis is common in Classic Autosar. Here, the connected hardware is checked cyclically for errors and any errors found are stored in the Diagnostics Management. The error reaction defined by the error of a component during creation of the effects analysis, i.e., the Failure Mode and Effects Analysis (FMEA), is triggered by the error event.
For example, in the case of a "Stuck at High" error, the opening of a low-side driver to enable an actuator that is incorrectly and permanently connected to be switched to a second independent path. The electrical problem is hereby conclusively tackled at the component level first and, as a result, one switching function and at least one actuator fails.
The failure of an actuator will inevitably have an effect on the system into which it is integrated. In order to ensure that these effects are taken into account correctly, Autosar is equipped with the concept of events that can be used to inform other applications about changes that have occurred. The failure of this switching function would result, for example, in the "Lower lift axle" function of a commercial vehicle no longer being available at system level. The affected function will then also receive a corresponding error code at this level.
The effects on the system, ECAS in our example, are taken into account in the system-FMEA and further follow-up actions are triggered by event. In our ECAS-example, this would result in the function "Raise functional lift axle" being blocked in order to avoid a reduction in the permissible vehicle load capacity due to the raising of the lift axle, which is still technically possible.
The failure of the "lift axle" system function has different effects on the vehicle. If the current lift axle remains lowered, this affects only the system properties and leads to a decrease in the ease of steering, increased fuel consumption, and wear on the tyres.
In the case of the failure of a raised lift axle, the available payload is reduced, which would have a significant impact on the availability of the vehicle and may necessitate on-road service of the vehicle to reduce the load.
An Onboard Diagnostic Tester collects the incoming error events here via DoIP, then makes decisions on how to proceed with the situation, and is of course available for further analyses in the case of on-road or off-road services. During this process, the OnBoard Tester can access not only original UDS diagnostic information, but as an Adaptive Autosar application, it can also actively access other interfaces from other applications via the ARA::COM interface for in-depth analyses.
The amount of data to be analysed and the mutual dependencies between the control units and their applications in the development of control units are increasing, which makes diagnostic development more complex. The classic separation between the development of control units and (after-sales) diagnostic development must therefore be eliminated in the future to enable more effective and efficient developments in this area.
The E/E development process starts with the requirements to be met by a vehicle, including the planned variability. The state of the art in this case is to import the specification data of a requirements management system into a vehicle data editor. The architecture of the control units is further specified in this vehicle data editor and the communication requirements (conventional: a "CAN matrix") are defined. Modern tools allow both the Autosar data (DEXT) and the diagnostic data (ODX) to be specified together at the same time and to be managed in a common database.
There is a large area of overlap between the contents of these two data formats, for example, in the case of DTC and DID. However, both formats contain all the necessary information for the development of control units. In the case of DTCs, ODX lacks approximately 40 attributes that describe a DTC in the control unit, such as the priority of the error and the debouncing strategy to be used.
In order to enable a developer to work effectively and efficiently when adding or modifying a DTC, it is almost vital that he should create and manage definitions only in one place for this purpose. Once a tool has all the necessary information, DEXT and ODX data can be generated from it, and, if changes are made later, these are also reimported and exported back into the respective other format.
This ensures coherence of the ODX and DEXT data, meaning that a function developer needs only one tool for his daily work. The changes are reflected in both areas at the touch of a button.
This process enables the creation of all necessary data formats for development and after-sales. In addition, test sequences can be generated automatically to verify the actual diagnostic behaviour of the control units.
This brings effective diagnostic options directly into the vehicle in conjunction with the various diagnostic layers, i.e., Component, System and Vehicle, of an Adaptive Autosar control unit. Trouble-free operation and a high level of reliability are thereby ensured to the greatest possible extent. In the case of errors, prompt diagnosis adapted to the vehicle variant is provided.
Thanks to intelligent problem management, complex functions such as ADAS can retain their best possible range of functions even if a subsystem malfunctions.
Diagnostics therefore retains the necessary prerequisite for adapting to the ever-increasing requirements of complex autonomous systems of the future. Diagnostic testers will be integrated into vehicles having high-performance computers with sufficient resources for these testers. This will make diagnostics more comprehensive and mobile!
