Open car electronic control platform based on MPC555

Based on the MPC555 microcontroller hardware platform, this design builds an open automotive electronic control platform that conforms to the OSEKIVDX standard.

Key issues in the design of open car electronic control unit

According to the definition of IEEE, the open control system must enable the corresponding execution program to run on different platforms, seamlessly connect and interoperate with other system applications, and provide users with a consistent style of interactive interface. This definition clearly sets out the characteristics and design key of an open control system that can be interoperable, reusable, scalable, and interchangeable.

In addition, because the vehicle use environment changes greatly, the control system requires strong adaptability, can dynamically configure the system according to changes in the environment, switch the algorithm components online and change the interconnection between components.

In terms of hardware, because the hardware structure is relatively fixed, the system upgrade basically adopts the method of component replacement or increase or decrease, and the update cycle is relatively long. Therefore, its openness focuses on the versatility and adaptability of hardware systems in the field of vehicle control. That is to say, the hardware system should adapt to the resource requirements of the vehicle control system for different control objects and control models, and also pay attention to the system openness. Connected hardware support.

OpenECU hardware system design

The system hardware architecture adopts Freescale's MPC555 as the control core, which consists of power module, storage system, reset circuit and interface module. Since the system is oriented to automotive electronics applications, in order to ensure the openness of the system in the automotive electronics field, the interface signals commonly used in the automotive electronics field should be processed, and corresponding dedicated interface chips are used to meet the requirements. At the same time, the system provides a wealth of I / O resources is also conducive to meeting the requirements of openness. The system architecture is shown in Figure 1.

Figure 1 system architecture diagram

1 system CPU selection scheme

The platform uses the processor MPC555 specially developed for the automotive electronics and other fields. Based on the analysis of the MPC500 series of microcontroller functions, the reasons for choosing MPC555 are as follows: CPU processing capability can meet the needs of the algorithm for computing tasks and floating-point computing capabilities; on-chip resources are abundant, many functional modules such as TPU, MDA and CAN Etc., specially tailored for the automotive electronics industry, the integration of various control function modules on the chip, so that the system does not need too many external functions to drive the chip, and the hardware wiring is reduced, the cost is reduced, which helps to improve the reliability of the system; With a large internal memory capacity, the user can freely choose whether to use the external memory if the requirements are met, which is beneficial to cost saving and reliability.

2 Design of external expansion memory system

The MPC555 microcontroller has 448KB Flash on the chip and only provides 32KB of SRAM. It may not be enough to store space in some complicated control occasions. In order to enhance the adaptability and provide sufficient resources for users, this design also has external SRAM and Flash. Memory chip. Flash uses AMD's AM29LV160DB for a total of 2 pieces. The total storage capacity is 4MB. The read/write operation has a supply voltage range of 2.7 to 3.6V and an access time of 90ns. SRAM selects ISSI's IC61LV5128-10T chip, a total of 4 pieces, the total storage capacity is 2MB. The access time is 10ns and the supply voltage is 3.3V.

The memory controller in MPC555 provides interface functions for EPROM, static RAM, Flash, EEPROM and other peripheral devices. A total of four memory segments are provided, which are respectively selected by four chip select signal lines CS[0]~CS[3]. To make choices, support read and write operations. CS[0] is also used as the selection signal line for the program entry address section when the system boots. According to this feature, the system can be configured as a Flash boot mode. CS[1] acts as an external chip select signal for the SRAM. Figure 2 shows the connection diagram of the MPC555 microcontroller external expansion Flash and SRAM memory. Where WE[0:3]/BE[0:3] is the write enable/byte enable signal line, where WE[0]/BE[0] confirms the valid data on the data bus DATA[0:7], WE[1]/BE[1] confirms valid data on data bus DATA[8:15], WE[2]/BE[2] confirms valid data on data bus DATA[16:23], WE[3] /BE[3] confirms the valid data on the data bus DATA[24:31]. OE is the output valid signal and CE is the chip select valid signal. Since the MPC555 microprocessor is word-addressed, the lower two bits of the address line are not used to avoid address collisions.

Figure 2 MPC555 microcontroller external expansion Flash and SRAM memory connection diagram

3 Lamda sensor signal conditioning

The LM9040 is a two-channel sensor interface circuit consisting of a differential amplifier with two independent Lamda oxygen sensor sampling inputs. The Lamda sensor monitors the engine exhaust and produces a measured voltage signal based on the air/fuel ratio. The LM9040 converts the ±2V sensor differential measurement signal to an A/D converted output voltage suitable for a 5V reference voltage. The circuit is shown in Figure 3.

Figure 3 Lamda sensor signal conditioning circuit diagram

4 CAN communication bus design

In order to realize distributed control and real-time data exchange in the powertrain control system, it is necessary to adopt a network bus method with high transmission rate, strong anti-interference ability and high reliability. With its outstanding real-time, reliability and flexibility, the CAN bus is the most competitive in many existing automotive network communication standards.

Two CAN bus controller modules TouCAN have been embedded in MPC555. TouCAN complies with CAN2.0B technical specifications, compatible with standard (11-bit identifier) ​​and extended (29-bit identifier) ​​message formats, so this design uses integration. The way the controller implements the CAN node. To carry out CAN bus communication, it is also necessary to connect a CAN transceiver. In this system, the interface chip PCA82C251 between the CAN controller and the physical bus is selected. It is worth noting that 120Ω resistors need to be added at both ends of the bus, which plays a very important role in matching bus interference. Ignoring them will greatly reduce the anti-interference and reliability of data communication, and even fail to communicate. The communication medium is twisted pair. In order to enhance the anti-interference ability and remove the noise generated during the transmission of the signal, the high-inductance common-state filter ZJYS81R5 designed by TDK for the CAN bus is used.

OpenECU software system design

OpenECU's software system hides the details of the underlying hardware and device management from the user according to the requirements of openness, and encapsulates the system into hardware abstraction layer and operating system layer. The system structure is shown in Figure 4.

Figure 4 OpenECU software system structure

The hardware resources of the hardware abstraction layer management platform include three main parts: device driver for hardware system, hard interrupt management, system debugging and diagnostic support. It is the manager of the hardware interrupt of the system, generates and maintains the interrupt vector table, provides support for operating system interrupt management; provides the operation of the device operation for the operating system by encapsulating the hardware device resources; and responds to the debugging system by means of interrupt driving Service to perform system status monitoring.

OSEKIVDX provides a set of standards for automotive embedded operating systems and related services to promote coordination between different devices, providing software developers with a unified programming interface to improve software reusability and interchangeability. Sex. OpenECU chose TH-OSEK operating system as the operating platform for the system platform and user control algorithm for managing hardware and software resources. Mainly because of its strong real-time performance, with a standardized application program interface, providing standard system services for the control model, which facilitates the implementation and porting of the model. In addition, in order to be suitable for a wide range of target processors and support real-time programs running on a wide range of hardware, the OSEK operating system is highly modular and flexible. These features are clearly consistent with the openness that OpenECU's open development platform hopes to achieve. OpenECU uses the operating system to complete the further encapsulation of the device, provides a standardized service interface for the control model, and meets the requirements of device multiplexing and control real-time. In addition, the TH-OSEK operating system defines an open network management and communication system, which is convenient. The implementation of the control node is dynamically configured.

For system diagnostics and testing, this design focuses on providing a platform and means to implement diagnostic and testing services, regardless of specific diagnostic and test items. These features can be defined by the system on a case-by-case basis. OSEK ORTI implements basic service support for system diagnostic test applications, and provides an interface for querying and monitoring the OSEK operating system. Through the upper layer diagnostic service, the system information of the system can be obtained, and the basic operation of the target is provided for the diagnostic service. means. This part is the basis for the implementation of the system diagnostics and test functions, together with the diagnostic communication service to achieve distributed debugging and diagnosis of the target.

Conclusion

The preliminary practical use proves that the platform can facilitate users to build a composite vehicle control system, effectively improve the reliability of the system, and has high practical value.