Development and design of OSEK configurator based on OSEK real-time operating system

“This paper introduces the process of configuring OSEK real-time operating system and application programs through OIL language in the integrated development environment, including the realization of functions such as reading, editing, saving OIL files and automatically generating codes using a graphical user interface; using XML technology and The OIL language parser ensures the portability, extensibility and reusability of OIL files.

“

Authors: Pei Chao; Li Hua; Wang Yanjun; Ding Zhisheng

This paper introduces the process of configuring OSEK real-time operating system and application programs through OIL language in the integrated development environment, including the realization of functions such as reading, editing, saving OIL files and automatically generating codes using a graphical user interface; using XML technology and The OIL language parser ensures the portability, extensibility and reusability of OIL files.

With the rapid development of the automobile industry, automobiles have higher and higher requirements for control, communication, network management, etc. The hardware platform based on 32-bit microcontroller, the software platform based on embedded real-time operating system and the network based on CAN bus Communication platforms have gradually become the mainstream of today’s automotive electronics industry.

1 Introduction to OSEK/VDX specification

In terms of embedded real-time operating systems, in order to meet the development needs of increasingly large and complex automotive Electronic control software, to achieve the portability of application software and the compatibility between control modules of different manufacturers, in 1993 the German automotive industry jointly launched a The open system and interface of automotive electronics – OS-EK/VDX specification (hereinafter referred to as “OSFK specification”), aims to provide an open-structured industrial standard for distributed control units on automobiles. The OSEK specification makes a more comprehensive definition and regulation of the automotive electronic control software development platform from the aspects of real-time operating system (RTOS), software interface, communication and network management. Although the specification is still being perfected, a complete set of solutions it proposes will be the development direction of future automotive electronic software development.

In order to achieve the goal of portability of OSEK software, the OSEK specification defines a method for configuring OSEK applications – Universal Implementation Language OIL. OSEK configurator is a tool that uses a graphical user interface to configure OIL files according to user needs, and finally generates OSEK real-time operating system initialization code. It is an essential part of developing a real-time operating system that conforms to the OSEK specification.

2 Main features of OSEK Configurator

The development process of OSEK application is shown in Figure 1. The user can statically configure the properties of the operating system and all system objects according to the requirements of software and hardware through the OSEK configurator. After the configuration is completed, the OSEK configurator generates an OIL configuration file that conforms to the OSEK specification, and further generates C code and header files related to the operating system to provide the necessary system parameters for the initialization of the OSEK real-time operating system. In order to ensure software compatibility, OSEK configurator can also directly read OIL files conforming to OSEK specifications from outside to complete the process of generating OS static system files.

After the user completes the application code writing and OIL file configuration, the code generated by the OSEK configurator, part of the operating system kernel and the application program are cross-compiled together, while other operating system kernel codes are integrated as a library by the linker. This paper mainly studies the process of generating OIL configuration files and static system files that conform to the OSEK specification through the OSEK configurator (shown in the dotted line in Figure 1).

3 Implementation of OSEK Configurator

3.1 Implementation of Graphical User Interface GUI

The OIL language description of an OSEK application contains a set of OIL object descriptions, namely CPU, OS (operating system), APPMODE (application program mode), ISR (interrupt service), RESOURCE (resource), TASK (task), COUNTER (counter). ), EVENT (event), ALARM (alarm), COM (communication subsystem), MESSAGE (message), IPDU (external communication), and NM (network management). Among them, the CPU is the container for the remaining OIL objects. OIL defines standard types for its objects, each of which can be described by some attributes and parameters.

For different OSEK implementations, the method of generating OIL configuration files is different. Due to the complexity of writing OIL files by users themselves, it is very necessary to have a visual graphical user interface GUI with context-sensitive help in the integrated development environment. In an IDE, an OSEK configurator with GUI needs to include the following components:

◇ A list of OSEK objects following Windows Explorer format, users can add and delete DIL objects as needed;

◇A chart to Display the properties of each object (including standard properties and implementation-related properties), the user can change the properties of the object and update the OIL file in real time;

◇ A window for recording and display.

The OSEK configurator working interface of the integrated development environment is shown in Figure 2, and the management and display of its data are realized by XML technology.

XML defines the data structure in an open self-describing way, which can highlight the description of the structure while describing the content of the data, so as to reflect the relationship between the data. It is equivalent to a container that can be used to store various objects defined by OIL in the OSEK specification. For each OIL object, its attributes and sub-attributes contain different data structures, which can be easily represented by the XML tree structure; and for the same type of object that contains the same attributes and sub-attributes, it can be represented by the same XML template. .

Because XML technology can easily store, describe and manage structured data, and effectively separate data and data display, therefore, using XML technology in OSEK configurator to realize the configuration of OIL file graphical user interface is a Very convenient and efficient.

3.2 Using XML technology to configure OIL objects

The XML-based OSEK configurator stores the attributes defined by the OIL file in the initialized XML template file and specifies its default values. When the user adds or deletes OIL objects or modifies the attributes and parameters of the objects, the synchronization between the user configuration interface and the XML file can be achieved through the KML parser. The process is shown in the dotted line in Figure 3.

For example, when a user configures an OIL object ALARM, he needs to specify three properties, which are the alarm attachment timer COUNTER, the alarm action ACTION and whether to automatically start AU-TOSTART. Among them, ACTION and AU-TOSTART contain their own sub-attributes, and these data can be easily managed and modified by using XML technology.

The properties of an alarm configured through the GUI are as follows: the alarm is attached to the timer counterA, which adopts the automatic start mode, and its initial response time and periodic response time are 30ms and 20ms respectively. The OS-EK configurator reads these attribute values ​​through the XML parser and saves them in the XML source file alarm. xml. Below is the source code of this XML file;

3.3 Using XSLT technology to generate OIL files

After the OIL information configured by the user is saved as an XML file through the GUI, the OIL configuration file that conforms to the OSEK specification is generated by using the XSLT technology. The XSLT document itself is a good XML document, which is linked to the XML document that needs to be transformed, and the parsing and transforming process of the XML document is realized through the XSLT processor. The process of XSLT transformation is shown in the dotted line in Figure 4.

For example, the file alarm.2 that saves the ALARM configuration information in Section 3.2. xml, by defining the XSL style sheet file xml20il. xsl converts it to a standard OIL file. In order to ensure the universality of XSL files, a frame template template is designed for each level node of the input XML document, that is, a frame template is defined for each attribute and some sub-attributes of the OIL object. In this way, when OIL objects are added and deleted, the XSL file can be transformed quickly without any modification. Use Microsoft msxml 4 . o As: XSLT processor, defines the output method of the transformation as text format.

Convert in Section 3.2. Part of the key source code of the KML file is as follows:

3.4 Read OIL configuration file and generate code

In order to realize the portability and reusability of OIL files, the OSEK configurator also needs to realize the function of directly reading OIL files from outside (which can be manually written by users or generated by other OSEK implementations), and displaying and modifying attribute configuration through GUI. This process requires an OIL language parser, which converts the OIL file into an XML file and provides it to the GUI, and generates operating system-related C code and header files. This component develops OIL language parsers through LEX and YACC languages.

3.4.1 Constructing a Parser Using ALEX and AYAGO

Parser Generator is an integrated development tool for developing compilers using LEX and YAC++ languages ​​under Windows environment, including compiler construction tools ALEX and AYACC. ALEX and AYACC can not only convert LEX and YACC source programs into C language lexical and grammatical analysis programs, but also generate lexical and grammatical analysis programs of C++ and Java code according to user needs.

The parsing process of the OIL language parser includes lexical analysis, syntax analysis, error handling and object code generation. First, write LEX and YACC source files according to the objects and attribute values ​​and grammar rules in the OIL file specification, and automatically generate the lexical analysis class OilLexer and the grammar analysis class OilParser with C++ language code through ALEX and AYACC, and overload and add Yizhai Class member function; then these two classes are added to the VC project to realize the error handling and automatic code generation of the program, so as to develop the OIL language parser. The whole parser design principle is shown in Figure 5.

3.4.2 Design of Lexical Analysis Class and Syntax Analysis Class

In the lexical analysis stage, the scanning program decomposes the character sequence in the OIL file, removes self-characters such as spaces and line breaks, and collects the recognized word symbols into token units. If a lexical error is found during analysis, the error handler is transferred. ALEX’s input rules document, Lexer.l, consists of the following 3 parts:

◆Declaration section. Contains the required header files and definitions of the lexer classes.

◆ Rules section. Define the keywords of regular expressions and OIL objects, then add the C++ language source code for the corresponding pattern processing, and finally send the token to the parser class OiiParser. E.g:

◆Program part. No other extra functionality is required when designing the OIL scanner, so it is empty.

In the parsing phase, the parser obtains the tokenized source code from the lexical analysis class, and completes the parsing that defines the structure of the OIL language. AYACC input specification document Parser. y also includes 3 parts: declaration part, rules part and program part. In the declarations section, include the header files required by the OilParser class and declare the token tokens returned from the lexer. The rules section analyzes the grammar rules of the OIL file. The syntax of the OIL file follows the Backus-Naur Normal Form (BNF), and for the definition of each OIL object attribute, the OIL implementation is similar to a C structure definition. An OIL file consists of 3 modules: version, implementation definition and application definition. In BNF normal form, it can be expressed as:

The implementation definition contains all the attributes of an OSEK implementation, the data types and value ranges of these attributes may be restricted. Therefore, an error handling statement is set in the semantic rules section to check the data type and value range of the OIL object attributes. The characteristics of ALEX and AYACC make error detection simple and intuitive, and can be easily integrated with error handling classes, which is of great significance for making semantic judgments when reading OIL files from outside and ensuring the compatibility of OSEK configurator.

The application definition contains a series of objects and the assignment of the properties of these objects. In addition to the OS, COM and NM objects, the application can define multiple objects of the same type. According to the application definition rules, complete the formal grammar rules and C++ statements for semantic processing of each rule. In the processing statement, according to the XMI defined in the GUI part. Template format (MPC.xml in Fig. 4), one-to-one correspondence of the obtained objects and their attribute values ​​to the XML tree structure, thus completing the process of converting OIL files into XML files. Similarly, in the processing statement, the OIL object and its attribute values ​​are extracted according to the interface defined in the operating system, and the API functions and data structures conforming to the OSEK real-time operating system are generated, and placed in the C code and header file to complete the entire code. generation process.

4 Conclusion

The development of OSEK configurator is an important part of OSEK real-time operating system. In the process of development, using XML technology to facilitate the management and storage of data, the process of generating OIL files from a visual GUI is realized; using the advanced teaching and powerful error handling functions of the OIL language parser, the GUI can be read from the outside. The process of OIL file and code generation ensures the portability, extensibility and reusability of OIL file. This component runs stably in the integrated development environment, which is of great significance in developing the OSEK real-time operating system with independent intellectual property rights.