Implementation of Automotive Unified Diagnostic Services Based on AUTOSAR. Yue-yin XIE, Chao ZHOU and Feng LUO

Transcription

1 2017 2nd International Conference on Information Technology and Management Engineering (ITME 2017) ISBN: Implementation of Automotive Unified Diagnostic Services Based on AUTOSAR Yue-yin XIE, Chao ZHOU and Feng LUO Clean Energy Automotive Engineering Center, School of Automotive Studies, Tongji University, Shanghai, China Keywords: UDS, AUTOSAR, RTE, AUTOSAR OS, CANoe. Abstract. The AUTOSAR (automotive open system architecture) standard served as a platform upon which future vehicle applications are implemented and serve to minimize the current barriers between functional domains. This paper used the NXP chip MPC5643L to implement the unified diagnostic services (UDS) based on AUTOSAR software architecture with the help of the AUTOSAR tools, systemdesk from dspace, EB (Elektrobit) troses from Elecktrobit, and the GreenHills Multi. The AUTOSAR modules we used in this paper include RTE (Runtime Environment), AUTOSAR OS (Operating System), DEM (Diagnostic Event Manager), DCM (diagnostic communication manager), SchM (basic software scheduler), EcuM (ECU state manager), CAN (control area network) communication stack and memory stack, and so on. The UDS service code is integrated into the AUTOSAR software architecture, it is tested by CANoe. The result shows it is effective and reliable. Introduction Presently the standardization of low-level software in the automotive domain is led by the on-going partnership of automotive manufacturers and suppliers within the AUTOSAR consortium. The AUTOSAR Architecture distinguishes on the highest abstraction level between three software layers: Application, Runtime Environment and Basic Software which run on a Microcontroller, and the AUTOSAR Basic Software is further divided into four parts: Services, ECU Abstraction, Microcontroller Abstraction and Complex Drivers. Also the Basic Software Layer can be divided into several groups based on function. Example of Services are System, Memory and Communication Services. The CAN Communication Services are a group of modules for vehicle network communication with the communication system CAN, the purpose of the CAN Communication Stack is to provide a uniform interface to the CAN network and hide protocol and message properties from the application. The UDS software architecture is integrated in DCM, and the EB troses provided the interface for the implementation of the specific UDS services. We used the systemdesk to develop a SWC which used the DCM services and used the EB troses to configure the AUTOSAR Basic Software. The Multi compiler from Greehills are used to compile, download and debug the generated and handed code. CAN Diagnostic Communication Stack in AUTOSAR Diagnostic and Signal-Based Communication Path Diagnostic communication uses the module CAN driver, CANIF (CAN interface), CANTP (CAN Transport Layer), PDUR (protocol data unit router) and DCM. Figure 1. diagnostic communication path illustrated cases, in which multiple L-PDUs (i.e. frames) are received by the Driver module and sent on to the respective Interface module. The Interface module passes these L-PDUs to the Transport Protocol module as N-PDU. The transport protocol assembles an out of (potentially) multiple N-PDUs. This is finally routed to the DCM by the PDUR. Upon transmission, the frames uses the same path backwards. This requires the CANTP to segment a (large) into multiple N-PDUs. In signal based communication, the PDUR can route the to the COM 173

2 (communication) module, and then COM module send the signals to RTE[1]. CAN transport protocol is optional in a signal based communication. Signal-based communication Diagnostic communication Com DCM PduR Service Layer CANTp N-PDU CANIf L-PDU CAN driver Ecu Abstraction Layer Microcontroller Abstraction Layer Figure 1. Diagnostic and signal-based communication path. Configuration of CAN Diagnostic Communication The CAN driver module performs the hardware access and offers a hardware independent API (Application Programming Interface) to the upper layer[2]. There is one CanConfigSet in the CAN driver module, the CAN controller baudrate is 500kbps, and the CAN Tx processing type and CAN Rx processing type are both polling, so an os task is needed to call the Rx and Tx main function periodically. The Configuration of CAN hardware objects is show as Table 1. Table 1. Configuration of CAN hardware objects. CAN ID Message Type CAN Id Value Can MB(mail box) Type CAN Filter Mask CANHRO STANDARD 0x750 RECEIVE Accept All CANHTO STANDARD 0x751 TRANSMIT Accept All The CANIF is located between the CAN driver and upper communication service layers, i.e. CANSM (CAN State Manager), CANNM (CAN Network Management), CANTP (CAN Transport Layer), PDUR[3]. The CANIF provides a unique interface to manage different CAN hardware device types like CAN controllers and CAN transceivers used by the defined ECU hardware layout. Thus multiple underlying internal and external CAN controllers/can transceivers can be controlled by the CANSM based on a physical CAN channel related view. There is one CanIfInitConfiguration in the CAN interface module. The Hrh (hardware receive handles) and Hth (hardware receive handles) are configured as Table 2. Table 2. Configuration of CAN hardware object handles. CANHrH CANHtH The RxPdu and TxPdu are configured as Table 3. CanIfHrhIdSymRef CANHRO CANHTO 174

3 Table 3. Configuration of CanIfPdu. CanIf CanRxPduCanId CanIfRxUserType CanIfRxPduId CanIdType RPDU 0x750 CAN_TP STANDARD TPDU 0x751 CAN_TP STANDARD CANTP is the module between the PDUR and the CANIF module[4]. The main purpose of the CANTP module is to segment and reassemble CAN s longer than 8 bytes. The CANTP use the standard addressing format and physical addressing. And there is a CanTpTxChannel in CANTP module, the serial number of this channel is 0. The main part of CANTP configuration is shown as Table 4. The timing parameters are not specified in this paper. Table 4. Configuration of CAN hardware objects. CanT 4. Configurat prxnsduref RPDU CanTpTxNSduRef TPDU The routing table of PDUR includes the PDUs mentioned above[6]. The DCM module include three submodules: DSL (Diagnostic Session Layer) submodule, DSD (Diagnostic Service Dispatcher) submodule and DSP (Diagnostic Service Processing submodule)[5]. The DSL submodule ensures data flow concerning diagnostic requests and responses, supervises and guarantees diagnostic protocol timing and manages diagnostic states (especially diagnostic session and security). In the DSL submodule, we define a group of protocol timing, the specific parameters is shown as Table 5. Also a transmit buffer and a receive buffer for all protocols is configured in the DSL submodule, the buffer size is 256 bytes. Server Max Server Min Table 5. Protocol timing parameters. Server Max *Server Max *Server Min S3 Server The DSD submodule processes a stream of diagnostic data. The submodule receives diagnostic request over a network and forwards it to a data processor. Also the DSD submodule transmit a diagnostic response over a network when triggered by the data processor (e.g. by the DSP submodule). In DSD module, a DcmDSdServiceTable are configured. Inside the table, we configure the UDS service (e.g. Read Data By Identifier and Write Data By Identifier, the Service Handler name is Dcm_ReadDataByIdentifierHandler (0x22) and Dcm_WriteDataByIdentifierHandler (0x2e), these Handlers must be implemented by handed-code. The DSP submodule handles the actual diagnostic service requests. In the DSP submodule, a Did information is configured, The Did identifier is 0x0000, and Did size is 2 bytes. The security level configured in DCM is shown as Table 6. Table 6. Configuration of CAN security level. Security Level DCM_SEC_LEV_LOCKED 0 DCM_SEC_LEV_ALL 255 DCM_SEC_LEV_L1 1 DCM_SEC_LEV_L

4 The session level configured in DCM is shown as Table 7. Table 7. Configuration of CAN security level. Security Level DEFAULT_SESSION 0 ALL_SESSION_LEVEL 255 EXTENDED_DIAGSTIC_SESSION 3 PROGRAMMING_SESSION 2 CAN Network Management and State Management Stack in AUTOSAR Architecture of Network Management and State Management The network management and state management include the COMM (communication manager) module, CANSM, NM (network management), CANNM, the relationship among these modules is shown as Figure 2. ComM CanSm Nm CanNm (instance 1) CanNm (instance 1) CanIf Figure 2. Diagnostic and signal-based communication path. The COMM simplifies the control of the complete communication stack, the CANNM implemets the bus specific network management, and the NM module implements a bus-independent a bus-independent adaption layer and a coordinator algorithm. With this, the NM module can put several connected networks into sleep state synchronously. CANSM implement the bus specific start-up and shut-down[7]. Network States For each network channel, there is a specific state machine within the COMM module. This state machine has three states, full communication, silent communication and no communication. The full communication has two sub states, network requested and read sleep. The communication behaviors are different in different states. 176

5 Full commun ication Network requeste d Full commun ication ready sleep Silent commun ication No commun ication Table 8. Communication behaviours in different states. Message Message Network Wake-up transmission reception management/ capability On On Requested Not applicable On On Released Not applicable Off On Released User request Network indication Off Off Released User request Passive wake-up ECU Startup Flow in AUTOSAR The ECUM is responsible for system initialization, system shutdown and overall ECU state management[14]. A state machine exist in the ECUM, the state Machine provides the following states. Power on STARTUP WAKEUP STARTUP_TWO STARTUP_ONE WAKEUP_TWO RUN WAKEUP_REA CTION APP_RUN APP_POST_RUN WAKEUP_VALI DATION GO_OFF_ONE SHUTDOWN PREP_SHUTDOWN WAKEUP_ONE GO_OFF_TWO GO_SLEEP SLEEP RESET OFF With OS support Without OS support Figure 3. Diagnostic and signal-based communication path. In the STARTUP state, the ECUM enters the STARTUP _ONE state before the os is started. Init list zero and init list one is called in STARTUP_ONE, and the module initialization in list zero don t use post-build configuration parameters, All modules in list one initialized before the OS is started and so these modules require no OS support. Init list two and init list three are called in STARTUP_TWO. All modules in list two are initialized after the OS is started and so these modules may use OS support. These modules may not rely on the Nvram ReadAll job to have provided all data. All modules in list three are initialized after the OS is started and so these modules may use OS support. These modules may also rely on the Nvram ReadAll job to have provided all data. The init lists are configured as follows. 177

6 Table 9. Configuration of Init Lists. Init List Zero Init List One Init List Two Init List Three DET Mcu, Port, Fls, Can CanIf, PduR, Com, CanTp, Dcm, CanNm, Nm, Fee, NvM, CanSM ComM, Dem The ECU startup flow is shown as Figure 4. STARTUP_ONE Init List zero STARTUP_TWO Init SchM Init List one Select application mode (The EcuM) WdgM_SetMode Init List Two Get reset reason Start RTE Select application mode Init List Three Start OS Figure 4. ECU startup flow. AUTOSAR OS Configuration In the AUTOSAR OS, there must be an OS task which is used for polling, this task is configured as Table 10. Table 10. Configuration of Init Lists. Period (ms) Mapped functions OsTask_Polling 10 Can_MainFunction_Write() Can_MainFunction_Read() CanTp_MainFunction() Dcm_MainFunction() CanNm_MainFunction() CanSM_MainFunction() Dem_MainFunction() ComM_MainFunction() And the Os_Start is used to start up the ECU, and to enter into the Full communication mode in order to provide the communication ability to the DCM mode. The period of this task is 10ms, the flow diagram is as Figure

7 Get current EcuM state ECUM_STATE_SLEEP ECUM_STATE_STARTUP_ONE During Sleep call EcuM_MainFunction in an endless loop ECUM_STATE_RUN Call EcuM_StartupTwo() ComM_RequestComMode( 0,COMM_FULL_COMM UNICATION) Activate OsTask_Polling Figure 5. ECU startup flow. The Implementation of DidRead and DidWrite Services Software Component In this UDS service, the DCM module receive the request data from the CANTP module, and then request the RTE for services about the DidRead and DidWrite, and the services is the Condition Check Read, Read Data, Condition Check Write, Write Data. The DCM module is seen as an SWC, and the DCM module has at least a client-server interface, and this interface is used to generate a request to the SWC which was built in the Application layer and also has a client-server interface. This interface matched with interface in the DCM module. When the DCM module receive request from the CANTP module, if the received UDS service number is 0x22(0x2e), then the DCM module invoke the Dcm_Read(Write)DataByIdentifierHandler. In this handler, some operation invoke events are generated, and these events invoke the runnables in the SWC that built in the application layer, and in these runnables, the functions like Condition Check Read, Read Data, Condition Check Write, Write Data are provided. The runnables mentioned above are mapped to one OS tasks, and this task must have a higher priority than the task the Dcm_MainFunction has mapped to. The whole process of this UDS service is shown as Figure 6. DCM (Invoke Dcm_Read(Write) DataByIdentifierH andler) Operation invoke events SWC ConditionCheckRead ReadData ConditionCheckWrite CANTp WriteData Mapp to OS Task Figure 6. Process of this UDS service. The SWC in Figure 6. was implemented in Systemdesk, the system description arxml file is exported from the Systemdesk, and then is imported to the EB troses for further configuration. 179

8 Implemetation of Dcm_ReadDataByIdentifierHandler In the EB troses generated code, we can use the pmsgcontext which is the input parameter of the service handler to get the request data and store the response data. After the handler was finished, the DCM use data in pmsgcontext to generate a response. The flow diagram of Dcm_ReadData (Write) ByIdentifierHandler is show as follows. entry Check the length of the request data failed incorrectmessagelengthorin validformat success Get Did indentifier Did support service 0x22 in active session? DID security check ok? SecurityAccessDenied E_T_OK Set operation event Wait for ConditionRead(Write)Check E_OK Set operation event Wait for Read(Write)Data E_T_OK ConditionNotCorrect ConditionNotCorrect E_OK Store the response data Further DID avaliable? At least one DID is supported in the acitive session? Requestoutofrange Total response length exceeded Responsetoolong Positive response Figure 7. Dcm_ReadData(Write)ByIdentifierHandler flow diagram. 180

9 Test of DidRead and DidWrite Services At last, we test the DidRead and DidWrite Service by using the CANoe.ODXstudio, CANoe.Diva, and CANoe. We use the CANoe.ODXstudio, CANoeDiva to configure a test case to test the ECU, which is implemented by NXP chip MPC5643L. The ECU has passed the test, the result is shown as follows. This test case shows that the CANoe send a Did read request to read the data with id 0x0000, and the ECU returned the data value through a positive response. Figure 8. Test results. Conclusion This paper used the Systemdesk to build a SWC, which provide the DCM some service about the DidRead and DidWrite. And we also used the EB troses to generate the BSW for the ECU, so the ECU can implement the UDS service. At last, we use the CANoe to validate the UDS service. The whole process followed the AUTOSAR development process, so it is meaningful for the use of AUTOSAR tools. Acknowledgement This research was financially supported by the National Science Foundation. References [1] AUTOSAR Development Partnership. Specification of RTE, [2] AUTOSAR Development Partnership. Specification of CAN Driver, [3] AUTOSAR Development Partnership. Specification of CAN Interface, [4] AUTOSAR Development Partnership. Specification of CAN Transport Layer, [5] AUTOSAR Development Partnership. Specification of Diagnostic Communication Manager, [6] AUTOSAR Development Partnership. Specification of PDU Router, [7] AUTOSAR Development Partnership. Specification of CAN State Manager,