Design of vehicle body network electronic control system based on code generation

introduction

In the field of body electronics, a series of studies have been conducted at home and abroad. Chen Jiaqi and others from Shanghai University of Technology used industrial computers, related data acquisition cards and CAN bus intelligent interfaces to build a centralized body electronics test bench. Jiao Xiaowei and others from Harbin Institute of Technology used the Stateflow graphical modeling tool to build a body application layer software model that meets the AUTOSAR standard, and then used the Targetlink code generation tool to automatically generate code based on the model. Yue Guo and others from the University of Warwick in the UK compared the advantages and disadvantages of the development methods based on SysML and "Simulink+Stateflow" in the development process of driving information systems. This paper adopts a body network electronic control system development method based on a framework structure and high-level language description, and uses the UML modeling tool to realize the automatic generation of program code, which can further simplify the design and development process of the body network, improve software reusability, reduce development costs, and reduce human errors.

1 EA and code generation function

Enterprise Architect (EA) is a UML modeling and design platform developed by Sparx Systems, an Australian company. EA is compact, easy to use, and fully supports the UML standard; in addition to supporting all 13 types of graphics in the UML2.0 standard, it also supports other extended diagrams, including analysis diagrams, custom diagrams, requirement diagrams, maintenance diagrams, user interface diagrams, database model diagrams, documents, business modeling and business interaction diagrams, etc.

To facilitate expansion, customization and secondary development, EA provides a rich SDK. The Code Template Framework (CTF) is part of the SDK, and EA's code generation function is implemented through code generation templates based on this framework. The code generation template specifies the conversion process from UML elements to a given programming language, and its modification is implemented through the code template editor. The opening method is EA main menu Settings→Code Generation Template, or use the shortcut key Ctrl+Shift+P. The code generation template is written in plain text, and its syntax style combines the syntax characteristics of markup language and scripting language. This syntax focuses on three basic structures:

(1) Literal text. In the code generation template, except for blank lines, all text that is not a macro or variable definition or reference will be directly output to the generated code as literal text. For example:

class %className%

(2) Macros. Macros can be used to access element values ​​in UML models and to perform structured processing on generated code. All macros have two percent signs % in them. CTF contains six basic macros: template substitution macros, domain substitution macros, tag value substitution macros, control macros, function macros, and EASL code generation macros. It is these rich macro definitions that make EA's code generation capabilities powerful. Still using the above example, "%className%" is a domain substitution macro, which will be replaced by the current class name in the generated code. So if the current class is Foo, the output of the statement is "cl-ass Foo".

(3) Variables. The definition and reference of variables facilitate the storage and access of data in the code generation template. Variables in CTF are defined using weak types, that is, the data type of the variable can be ignored and a variable can be assigned values ​​of different data types. The value of a variable can come from various macros, literal text enclosed in double quotes, and references to other variables. The definition and reference of a variable use a dollar sign plus a legal identifier, such as $foo=%class Name%. The variable $foo will store the name of the current class. When you need to reference this variable, just use $foo.

2. Hardware and software design

In order to facilitate debugging and verify the effectiveness of the generated code, this design builds a body network demonstration test bench with CAN bus as the backbone and LIN bus as the lower layer network.

2.1 Hardware Topology

According to the function and location of the vehicle body electrical appliances, the topological layout of the test bench is shown in Figure 1. Among them, the thick solid line is the CAN bus and its nodes, and the thin solid line is the UN bus and its nodes. There are 8 nodes on the trunk CAN bus, which are both host nodes on the lower layer LIN network and CAN/LIN gateways. Among them, the data acquisition node is built using a USBCAN card, and the remaining gateway nodes use Freescale's 16-bit microcontroller MC9S12XSl28 as the main control chip.

MC9S12XS128 has both CAN network controller (MSCAN module) and LIN network controller (SCI module), so it only needs to connect the corresponding CAN network transceiver TJAl050 and LIN network transceiver TJAl020 to complete the hardware design of CAN/LIN gateway node. The functional block diagram of CAN/LIN gateway node is shown in Figure 2.

The LIN slave node uses the Freescale 8-bit microcontroller MC9S08DZ60 as the main control chip, uses its SCI module to connect to the LIN network transceiver TJAl020, and then connects to other peripheral actuators. The functional block diagram of the LIN slave node is shown in Figure 3.

2.2 Software Modeling

At present, most software compilers supported by single-chip microcomputers are based on C language, and there are no related concepts such as class and inheritance in C language. At the same time, for the consideration of portability, the software model adopts a layered idea. The software structure of the entire design is divided into 4 layers: the 0th layer is the macro definition of type definition and interrupt service program return value, the 1st layer is the abstraction of single-chip microcomputer and its internal functional module class, the 2nd layer is the abstraction of peripheral hardware class, and the 3rd layer is the abstraction of each node class of the vehicle body network. The upper class implements specific functions by calling the functions provided by the lower class. The dependency relationship of each layer is shown in Figure 4. Among them, the dotted line represents the calling relationship. The modeling methods of layers 1 to 3 are introduced in detail below.

2.2.1 Layer 1: Abstraction of MCU and its internal functional modules

The functions of the first layer are realized by reading and writing the registers of the microcontroller, so the member functions of the class are used to write the register reading and writing codes directly in the Initial box of the Behavior property of the member function. For example, the code to enable the MSCAN module in S12 is as follows:

CANCTL1(MSCANx)|=CANCTlLl_CANE_MASK;

CANCTL1 is a manually written function macro for the purpose of unified processing of multiple MSCAN modules and selection of a specific module. When used, only the MSCANx value needs to be assigned to the corresponding integer value (for MC9S12XS128, it can be 0 to 4).

2.2.2 Layer 2: Peripheral Hardware Class Abstraction

The second layer needs to call the operations of the first layer class, which can be achieved through the activity diagram. In the activity diagram, create a new Action, select CallOperation (call member function) or Call Behavior (call the behavior of the activity diagram) as needed, and then specify which member function or behavior to call (the parameters of the call are passed through the Arguments property of the Action). Finally, connect each Action according to the program flow.

Here, a data frame is sent using the CAN protocol (the upper layer protocol uses J1939) (the activity diagram is omitted - Editor's note). In order to achieve code generation for behavior diagrams (including activity diagrams), all behavior diagrams and their elements must be placed in a class. The code generated after the activity diagram is converted is as follows:

[page]

2.2.3 Abstraction of Node Classes in Layer 3-Car Body Network

In addition to the operations that need to be called in Layer 1 and Layer 2, Layer 3 also needs to model the Interrupt Service Routine (ISR). The modeling of ISR involves two issues: the return value of ISR and the location of ISR.

(1) ISR return value problem. CodeWarrior supports two ways to declare ISR. One is to use the precompilation directive pragma to define a TRAP_PROC symbol. TRAP_PROC will prompt the compiler that the following function is an ISR, and the compiler will use a special interrupt return instruction to end this function (usually an RTI instruction). This method requires modifying the PRM file in the CodeWarrior project at the same time to link the ISR with the vector in the interrupt vector table, which is not convenient for UML modeling.

Another way is to use the interrupt keyword similar to C51 and specify the corresponding interrupt vector number, so that the ISR declaration and the association with the interrupt vector table are completed at the same time. Modify the code generation template of the class in EA, add a stereotype and name it define, and add the corresponding template code. The core code is as follows:

After the modification is completed, in the modeling process, you only need to set the derived type of the class to define, set the class name to the newly defined symbol, and set the parent class of the class to the original symbol. Taking the return value of the receive interrupt of the CANO module as an example, you can set the class name to ISR_CAN0_RX and the parent class to interrupt 38void (this parent class does not exist). The final generated code is as follows:

#define ISR_CAN0_RX interrupt 38 void

Then specify the return value of the ISR as ISR_CANO_RX.

(2) ISR positioning problem. The declaration and definition of the interrupt service program must be located in the non-banked area, which is achieved by using "#pragma CODE_SEG NON_BANKED". At the same time, "#pragma CODE_SEG DEFAULT" needs to be added at the end of the interrupt service program, otherwise the subsequent functions will also be located in the non-banked area and cause errors. Therefore, the interrupt service program must be surrounded by "#pragma CODE_SEG NON_BANKED" and "#pragma CODE_SEG DEFAULT". This can also be achieved by modifying the code generation template. Combined with the macro definition of the ISR return value, it is only necessary to output the above two pragma pre-compilation instructions before and after the function when the first 3 characters of the function return value are "ISR". The core part of the code generation template that generates the ISR declaration is as follows:

Still taking the receiving interrupt of the above CAN0 module as an example, the function declaration finally generated is as follows;

3 Debugging and Verification

In addition to using the USBCAN card as a data acquisition node, this design uses a PC oscilloscope PicoScope 5203 with bus protocol analysis software WaveBPS to capture the two bus signals and perform protocol analysis in order to verify whether the implementation of the two bus protocols meets the standards, view the values ​​of each field in the bus frame more intuitively, and detect whether frame errors occur on the bus at any time. The two channels of PicoScope can capture signals on the CAN bus and LIN bus at the same time, which further facilitates the debugging of the gateway node.

Figure 5 shows the CAN data frame sent to the headlight node (destination address 0x20) when the control panel node (source address 0x26) turns on the left turn signal. The bit marked as S is the fill bit automatically inserted according to the bit filling rule. Figure 6 shows the data frame sent to the LIN bus by the headlight node after receiving the above CAN data frame according to the gateway routing strategy and frame conversion rules.

4 Conclusion

This design uses the code generation function of EA to modify the code generation template to meet the requirements of C language and compiler in the development of the body network electronic control system, and carries out the development and preliminary experimental verification of the body network system. This method greatly facilitates design and development and can improve the reliability of the system.