Embedded software system architecture and application method

Abstract

The invention discloses an embedded software system architecture and an application method. The software system architecture comprises a system layer, and an application layer, a code link layer, a function module layer, a universal peripheral access layer and a hardware driving layer which are sequentially ranked from top to bottom. The system layer interacts with other layers to provide systematic services; the application layer is used for dividing a first task and running the first task; the code link layer is used for linking codes of the application layer and bottom layer codes; the functional module layer is used for managing functional components and lower-layer interfaces; the universal peripheral access layer is used for dividing and running a second task associated with the underlying code; and the hardware driving layer is used for driving the chip and the chip peripherals and packaging a driving interface. According to the method, the architecture of each level is simple, each level has different functions, the implementation cost is low, design cutting and expansion can be carried out according to the design requirements of an actual system architecture, cross-field application can be realized, and the portability and universality are high.

Description

Technical Field

[0001] The present invention relates to the technical field of embedded systems, and in particular to an embedded software system architecture and an application method. Background Art

[0002] With the continuous development of the Internet of Things, embedded devices based on microcontroller MCU (Microcontroller Unit) are also widely used in people's lives, such as smart homes and wearables, medical equipment, industrial control equipment and automotive electronic equipment. However, there are many types of embedded devices, and the specifications and standards in different fields are inconsistent, which increases the cost of software development and deployment.

[0003] In the traditional embedded software development process, most projects simply divide the software into two parts: application APP (Application) and board support package BSP (Board Support Package). However, since the layering is too general, it is difficult to cope with increasingly complex applications in the actual development process, and the code coupling is high, making it difficult to port to other projects.

[0004] Many MCU embedded devices are used in today's intelligent cars. In order to standardize the development of these devices, Germany has proposed an OSEK standard, namely open systems and the corresponding interfaces for automotive electronics. Although OSEK has improved the portability and scalability of automotive electronics software to a certain extent, it lacks certain versatility, that is, it is not suitable for other MCU embedded fields, such as consumer electronics and industrial electronics. With the development of automobiles, OSEK can no longer meet the existing development needs, so some German automobile alliances have proposed a new architecture, namely the automotive open system architecture AUTOSAR (Automotive Open System Architecture), among which the MCU is related to the AUTOSAR Classic Platform. AUTOSAR adopts a layered and modular design, which brings certain conveniences to the software development of automotive electronics. Although its standard is open, the specific implementation process of AUTOSAR is very complicated. If enterprises want to use it, they need to purchase its software or implement it by themselves, which leads to high purchase or implementation costs. Therefore, AUTOSAR is not suitable for promotion to consumer electronics and other fields, and it requires a large amount of chip resources, is not suitable for some MCU chips with limited resources, and has high development costs.

[0005] Therefore, how to design a highly versatile MCU-based embedded software system architecture is an urgent problem to be solved in this field. Summary of the invention

[0006] The present invention provides an embedded software system architecture and an application method, which are used to solve the technical problem that the existing MCU-based embedded software system architecture has poor versatility and is difficult to apply to different field scenarios.

[0007] The first aspect of the present invention provides an embedded software system architecture comprising: a system layer and an application layer, a code link layer, a function module layer, a general peripheral access layer and a hardware driver layer in order from top to bottom;

[0008] The system layer exchanges information with other layers to provide system services;

[0009] The application layer is used to divide the first task according to the preset task scheduling conditions and run the first task; the code of the application layer is separated from the underlying code;

[0010] The code link layer is used to link the code of the application layer and the underlying code, and encapsulate the linked interface and the interface of the underlying code according to a unified naming format;

[0011] The functional module layer is used to manage functional components and lower layer interfaces;

[0012] The universal peripheral access layer is used to divide and run the second task associated with the underlying code according to the preset task scheduling conditions;

[0013] The hardware driver layer is used to drive the chip and chip peripherals, and encapsulates the driver interface and provides it to the upper layer and the system layer for use.

[0014] Further, the application layer includes an application layer task unit and a business logic unit;

[0015] The application layer task unit is used to divide the first task according to a preset task scheduling condition;

[0016] The business logic unit is used to implement the logic code of the application layer and at the same time serve as the executor of the first task, and to connect with the code link layer through variables and function interfaces.

[0017] Further, the code link layer includes a code link unit and an encapsulation unit;

[0018] The code linking unit is used to assign values ​​and implement specific variables or function interfaces required by the application layer, and link the interface of the code of the application layer with the interface of the underlying code;

[0019] The encapsulation unit is used to encapsulate the linked interface and the interface of the underlying code according to a unified naming format.

[0020] Further, the functional module layer includes FML components and functional logic units;

[0021] The FML component is associated with the functional component and supports any operation mode of adding, deleting and combining with a third-party functional component package;

[0022] The functional logic unit is used to implement functions and encapsulate interfaces of the GIF interface of the universal peripheral access layer and the interface of the FML component.

[0023] Further, the universal peripheral access layer includes a universal peripheral access layer task unit and a universal peripheral access layer interface;

[0024] The general peripheral access layer task unit is used to divide and run the second task associated with the bottom layer code according to the preset task scheduling conditions, and run the functional tasks that need to be processed periodically at the functional module layer;

[0025] The universal peripheral access layer interface is used to encapsulate the function interface associated with the second task, and encapsulates the interface of the functional module layer in the form of a callback function to be responsible for the interface transmission between the functional module layer and the hardware driver layer.

[0026] Furthermore, the hardware driver layer is specifically used to initialize and configure chip registers, start the peripheral functions of the chip, and encapsulate the driver interface for use by the upper layer and the system layer; and use the system resources of the system layer according to usage requirements.

[0027] Further, the system layer includes an operating system management unit, a resource management unit and a SYS component;

[0028] The operating system management unit is used to create and schedule system tasks and provide system services through the operating system when the operating system is deployed; when the operating system is not deployed, the scheduling of system tasks is simulated through the chip timer;

[0029] The resource management unit is used to manage some public resources and function interfaces;

[0030] The SYS component is associated with a systemic component.

[0031] Furthermore, the code files of the software system architecture are stored in a hierarchical storage mode;

[0032] In the hierarchical storage mode, the Library folder is used to store the register library officially provided by the MCU chip for the hardware driver layer to call; the Source folder creates different folders according to the various levels of the software system architecture and the sub-modules within the levels to store different source code files in layers.

[0033] Furthermore, the system architecture supports single-core MCU chips and multi-core MCU chips, and when the software system architecture is extended to a multi-core MCU chip, each MCU chip core runs independently, and the Source folder is jointly managed by the System folder and multiple SubSystem folders. The System folder is used to store content related to starting the multi-core system; each SubSystem folder creates different folders according to the various levels and sub-modules within the levels of the software system architecture associated with each MCU chip core, which are used to store different source code files in layers.

[0034] A second aspect of the present invention provides an application method of an embedded software system architecture, comprising:

[0035] Obtain the system design requirements for the software system architecture and create a demand planning table for each layer of the system architecture;

[0036] Based on the demand planning table, create tasks associated with the application layer and the general peripheral access layer through the operating system management unit and implement scheduling operation, configure SYS components and manage resource management units to complete the configuration of the system layer;

[0037] Based on the demand planning table, initialize and configure chip registers and related peripherals, implement the driver interface, and realize the hardware driver layer;

[0038] Based on the demand planning table, divide and run the second task associated with the underlying code, and encapsulate the function interface associated with the second task to realize the universal peripheral access layer;

[0039] Based on the demand planning table, transplant relevant functional modules and encapsulate interfaces associated with the functional modules to realize the functional module layer;

[0040] Based on the demand planning table, encapsulate the interface of the underlying code according to a preset format, and reserve an interface position for linking the interface of the underlying code and the code interface of the application layer;

[0041] Based on the demand planning table, generate application layer code, divide and run the first task, and perform modeling design to implement the application layer;

[0042] The link relationship between the interface of the bottom layer code and the code interface of the application layer is adjusted according to the application code to form a new interface, and the new interface is encapsulated according to a preset format to realize a code link layer.

[0043] It can be seen from the above technical solutions that the present invention has the following advantages:

[0044] The present invention provides an embedded software system architecture and an application method, wherein the software system architecture includes: a system layer and an application layer, a code link layer, a function module layer, a general peripheral access layer and a hardware driver layer, which are arranged in order from top to bottom;

[0045] The system layer exchanges information with other layers to provide systematic services; the application layer is used to divide the first task and run the first task according to the preset task scheduling conditions; the code of the application layer is separated from the underlying code; the code link layer is used to link the application layer code and the underlying code, and encapsulate the linked interface and the interface of the underlying code in a unified naming format; the functional module layer is used to manage the functional components and the lower-level interfaces; the general peripheral access layer is used to divide and run the second task associated with the underlying code according to the preset task scheduling conditions; the hardware driver layer is used to drive the chip and chip peripherals, and encapsulate the driver interface for use by the upper layer and the system layer.

[0046] In the present invention, each level of the software system architecture is simple, with low implementation cost, and each level performs different functions, thereby reducing the complexity of the software system architecture and improving the maintainability of the software system architecture; it can be designed and tailored according to the actual system architecture design requirements, and the system layer, application layer and functional module layer support expansion. The software system architecture can be applied to embedded devices based on MCU chips in different embedded fields, with strong portability and versatility, thereby solving the technical problem that the existing MCU-based embedded software system architecture has poor versatility and is difficult to apply to different field scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0048] Figure 1 An architectural diagram of an embedded software system architecture provided for this application;

[0049] Figure 2 A specific architecture diagram of an embedded software system architecture provided for this application;

[0050] Figure 3 Design description diagram of the application layer provided for this application;

[0051] Figure 4 The design description diagram of the code link layer provided for this application;

[0052] Figure 5 Design description diagram of the functional module layer provided for this application;

[0053] Figure 6 A design description diagram of the general peripheral access layer provided for this application;

[0054] Figure 7 The design description diagram of the hardware driver layer provided for this application;

[0055] Figure 8 A design description diagram of the system layer provided for this application;

[0056] Fig. 9 A tree diagram of the file directory provided for this application;

[0057] Fig.10 A multi-core system description diagram provided for this application;

[0058] Fig.11 A tree diagram of the multi-core system file directory provided for this application;

[0059] Fig.12 An example description diagram of the embedded software system architecture provided in this application applied to the automotive electronics field;

[0060] Fig.13 An example description diagram of the embedded software system architecture provided in this application applied to the field of industrial electronics;

[0061] Fig.14 An example description diagram of the embedded software system architecture provided in this application applied to the field of medical electronics;

[0062] Fig.15 A flowchart of the steps of an application method of an embedded software system architecture provided in this application;

[0063] Fig.16 An overall implementation flow chart of an application method of an embedded software system architecture provided in this application. DETAILED DESCRIPTION

[0064] The embodiment of the present invention provides an application method of an embedded software system architecture, which is used to solve the technical problem that the existing MCU-based embedded software system architecture has poor versatility and is difficult to apply to different field scenarios.

[0065] In order to make the purpose, features and advantages of the present invention more obvious and easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0066] See also Figure 1 In the first aspect, the present application provides an embedded software system architecture, including: a system layer (System Layer, System layer) and an application layer (Application Layer, APL), a code link layer (Code Link Layer, CLL), a functional module layer (Functional Module Layer, FML), a general peripheral access layer (General Peripheral Access Layer, GPAL) and a hardware driver layer (Hardware Driver Layer, HDL) arranged in order from top to bottom.

[0067] The system architecture provided by the present invention is a universal open embedded software system architecture, namely EmbedSSA (Embedded Open Software System Architecture), which is designed based on the basic design principles of layered design, modular design, high cohesion and low coupling, scalability, generalizability and maintainability.

[0068] Among them, the basic design principles include: 1) Layered design: Divide the system into multiple layers, each layer is responsible for different functions, but the layers should not be too many or too few. 2) Modular design: Divide the decomposable functions in the system into multiple independent modules, each module is used to implement a specific function or business, so as to reduce the complexity of the system and improve maintainability. 3) High cohesion and low coupling: The elements within each module or layer should be closely related and jointly implement a certain function to improve the reusability and maintainability of the module. At the same time, the coupling between the upper and lower layers should be reduced to avoid cross-layer calls. 4) Scalability: The system should have good scalability, be able to introduce new functions, and be able to cut unused functions. 5) Versatility: The system should be able to be applied to different domain scenarios as much as possible, that is, it should be transplanted to other projects. 6) Maintainability: The design of the system should be easy to read, understand, modify and expand, so that the system can continue to evolve and maintain.

[0069] In the present invention, each layer plays a different role and implements a specific function or business, specifically:

[0070] The system layer exchanges information with other layers to provide systematic services. The system layer is the task management and scheduling center of the software system architecture, and its main function is to provide systematic services.

[0071] The application layer is used to divide the first task and run the first task according to the preset task scheduling conditions. The application layer can execute the first tasks of various practical applications, where the preset task scheduling conditions can be the execution cycle of the task or the specific functional category of the task; at the same time, the code of the application layer is separated from the underlying code, which can reduce the interdependence between the various levels in the system architecture and has strong maintainability.

[0072] The code link layer is used to link the application layer code and the underlying code, and encapsulate the linked interface and the underlying code interface in a unified naming format. In the present invention, the code link layer mainly plays the role of connecting the upper and lower layer codes (application layer code and underlying code), and can encapsulate the linked interface and the underlying code interface into an API (Application Programming Interface) interface with a unified naming format, which is convenient for transplantation to other projects, thereby reducing the project development cycle.

[0073] The functional module layer is used to manage functional components and lower-level interfaces to achieve the addition, deletion or combination of functional components, or to call one or a combination of multiple lower-level interfaces to jointly implement a certain part of the system architecture and ensure the scalability of software functions.

[0074] The general peripheral access layer is used to divide and run the second task associated with the underlying code according to the preset task scheduling conditions. The general peripheral access layer is also used to execute various tasks, but the executed tasks are only related to the underlying code, which is different and separate from the tasks of the APL layer. In this way, the application layer does not need to care about how the underlying tasks are run, thereby realizing the decoupling of the application layer and the underlying code. Among them, the preset task scheduling conditions can also be to divide different second tasks according to the execution cycle or peripheral function.

[0075] The hardware driver layer is used to drive the chip and chip peripherals, and encapsulate the driver interface for use by the upper layer and system layer. The hardware driver layer is responsible for connecting to the hardware registers of the chip peripherals to start the chip's peripheral functions so that the chip can operate normally.

[0076] The software system architecture provided by the present invention has a simple hierarchical architecture, low implementation cost, strong system readability, maintainability and portability, and can realize cross-domain applications (such as automotive electronics, consumer electronics, industrial electronics, medical electronics, etc. involving MCU chip embedded software technology related fields). It has strong versatility, and the system layer, application layer and functional module layer support expansion, and support engineering and technical personnel to add or cut, ensuring that the system architecture can be flexibly adjusted according to actual conditions.

[0077] See also Figure 2 , each level of the software system architecture performs different functions, and each level can also be divided into multiple independent modules. The following is a further detailed description of each level of the software system architecture:

[0078] See also Figure 3 In a specific embodiment, the application layer includes an application layer task unit (APL TaskUint, ATU) and a business logic unit (Business Logic Unit, BLU); the application layer task unit is used to divide the first task according to the preset task scheduling conditions; the business logic unit is used to implement the logic code of the application layer and at the same time serve as the execution body of the first task, and connect with the code link layer for variables and function interfaces. Among them, the ATU part can be divided into multiple first tasks (Task) according to the execution cycle, such as: 5ms task, 10ms task and 50ms task, etc.; it can also be divided according to specific functions, such as: vehicle lighting control task, wiper control task, etc. Among them, the task execution body inside the ATU is composed of one or more BLUs, and its internal task description is shown in Table 1. Finally, the Syetem layer performs unified task scheduling.

[0079] Table 1 Example of internal description of APL tasks

[0080]

[0081] The BLU part supports the logic functions of the code manually implemented by engineers (Non-modeling development), and also supports the generation of logic function code using MATLAB modeling development (using the Simulink tool in MATLAB to generate C language code). The implementation method of the logic code is flexible. After the logic code of the application layer is obtained, it is also necessary to connect with the CLL code link layer for variables and function interfaces, so as to control the bottom layer to execute functions.

[0082] In addition, the APL layer code can be separated (decoupled) from the underlying code. Then, when the actual project is delivered, the underlying code can be packaged into a library file lib without opening the underlying source code to the customer. The customer only needs to call the interface provided by the present invention to implement the application layer function to control the underlying code, thereby reducing the project development cycle.

[0083] See also Figure 4 In a specific embodiment, the code link layer includes a code link unit and an encapsulation unit; the code link unit is used to assign and implement variables or function interfaces required by the application layer, and link the interface of the application layer code with the interface of the underlying code; the encapsulation unit is used to encapsulate the linked interface and the interface of the underlying code according to a unified naming format.

[0084] For example, assuming Figure 4 APP_U.XxxValue and APP_Y.XxxValue are variables of the APL layer, and the APL layer will eventually call the two interfaces API_XxxGetValueFunction() and API_XxxSetValueFunction(), where APP_U.XxxValue and APP_Y.XxxValue are connected to the underlying FML layer, thereby realizing the transfer of values ​​in the code link layer to connect the upper and lower code layers. If the interface of the FML layer does not need to use the variables of the APL layer, it can be directly encapsulated and provided to the APL layer.

[0085] In the CLL layer, all code link interfaces and underlying code interface encapsulations should eventually adopt a unified naming style (with API as the prefix), i.e., API_Xxx, to facilitate porting to other projects and minimize the workload of modification, thereby reducing the project development cycle and improving efficiency.

[0086] See also Figure 5 In a specific embodiment, the functional module layer includes an FML component (FML Component) and a functional logic unit (FLU); the FML component is associated with the functional component and supports any operation mode of adding, deleting and combining with a third-party functional component package; the functional logic unit is used to implement the function and encapsulate the interface of the GIF interface of the general peripheral access layer and the interface of the FML component.

[0087] In actual applications, FML components can be added and deleted at will (provided that the chip memory resources are sufficient). In the software development process, engineers often use self-developed or third-party functional component packages, such as UDS protocol stack and LwIP protocol stack, and then combine these components to jointly implement part of the software functions. Therefore, this part ensures the scalability of the software functions.

[0088] FLU implements functions and encapsulates interfaces based on the GIF interface in the lower GPAL and the interface of the FML component. For example Figure 5 FLU 1 in the figure is the use of FML Component 1, that is, it realizes the control of FML Component 1 and provides interfaces to the upper and lower layers; FLU 3 calls one or more GIF interfaces of the lower layer GPAL to form a sub-function and provides it to the upper layer.

[0089] In addition to the implementation of sub-functions, FLU also has the function of encapsulating interfaces, which is mainly to standardize the interface format of the architecture, to distinguish which level of interface is called, to reduce the coupling between the upper and lower layers, and to avoid cross-level calls. In addition, in the process of implementing sub-functions in FML, operating system (OS) resources in the System layer may be used, such as communication mechanisms such as delay functions, semaphores, and message queues.

[0090] See also Figure 6 In a specific embodiment, the general peripheral access layer includes a general peripheral access layer task unit (GPAL Task Uint, GTU) and a general peripheral access layer interface (GPAL Interface, GIF); the general peripheral access layer task unit is used to divide and run the second task associated with the underlying code according to preset task scheduling conditions, and run the functional tasks that need to be processed periodically by the functional module layer; the general peripheral access layer interface is used to encapsulate the function interface associated with the second task, and encapsulate the interface of the functional module layer in the form of a callback function to be responsible for the interface transmission between the functional module layer and the hardware driver layer.

[0091] It should be noted that the GPAL layer has two main functions: ① Run the second task that belongs only to the underlying code. These tasks are separated from the APL layer. If the underlying source code is not open to customers, customers will not be able to see these tasks. Even if the first task of the APL layer is empty, the underlying code can still run normally. ② As a bridge between FML and HDL, if some peripheral drivers in the HDL layer do not need to be executed in the GPAL task, they can be directly provided to the FML layer after being packaged in the format, and the interface of the FML layer can also be called.

[0092] Specifically, the GTU part is similar to the ATU in the APL layer. It is also uniformly scheduled by the System layer and can also be divided into different tasks according to cycles or peripheral functions. It is used to execute peripheral tasks that require periodic processing in the underlying driver, such as: analog voltage periodic acquisition (ADC peripheral task), that is, periodic update and conversion of voltage values ​​and storage. When the upper layer needs to use it, it can call the function interface in GIF to obtain the analog voltage value. The application layer does not need to care about how the underlying tasks run, thereby realizing the decoupling of the application layer and the underlying code. In addition, the GTU also executes functions that require periodic processing in the FML layer, such as: the UDS protocol stack is used for vehicle diagnostic functions, and there is a state machine inside it. This state machine needs to run periodically to handle different situations. Since this component is at the bottom layer, it should not be placed in the APL layer, but should run in the GPAL layer. Table 2 shows the running code description inside the GPAL task.

[0093] Table 2 Example of internal description of GPAL task

[0094]

[0095] In the actual development process, in addition to the peripherals that run periodically, some peripherals require a higher response time, which is not suitable for periodic operation in the GTU task. Therefore, in addition to the interface encapsulation mentioned above, there is also an interrupt callback interface in GIF. In order to avoid cross-layer calls, the upper layer interface is encapsulated in the form of a callback function, and then the HDL layer calls the interface, which is equivalent to changing the name of the upper layer interface and calling it in the interrupt service function of the HDL layer, thereby ensuring the real-time performance of the peripheral data.

[0096] See also Figure 7 In a specific embodiment, the hardware driver layer is specifically used to initialize and configure chip registers, start the peripheral functions of the chip, so that the chip and OS can run normally; and encapsulate the driver interface for use by the upper layer and the system layer.

[0097] In addition, the system resources in the System layer can be used in the HDL layer. In the presence of an operating system (OS), the following method can be used to receive data: add the data to the message queue in the interrupt service function (interrupt enqueue), at which point the OS will generate an event notification of message queue enqueue, and then the GTU task in the GPAL layer will dequeue the data and retrieve the data (event dequeue) after receiving the enqueue event notification.

[0098] See also Figure 8In a specific embodiment, the system layer includes an operating system management (OperatingSystem, OS) unit, a resource management unit (Resource Management Unit, RMU) and a SYS component (SYSComponent).

[0099] An operating system management unit, which is used to create and schedule system tasks and provide system services through the operating system when an operating system is deployed; when an operating system is not deployed, the scheduling of system tasks is simulated through a chip timer;

[0100] For example, when an operating system is deployed, it is assumed that the operating system used in the MCU chip is a hard real-time system (RTOS), such as open source real-time operating systems such as FreeRTOS and RT-Thread. When there is an operating system, it can be used to create and schedule the tasks of the entire software system, as well as provide system services such as semaphores and message queues. When an operating system is not deployed, that is, the MCU does not use an operating system (bare metal), the chip timer can be used to simulate the scheduling of tasks, for example: the chip timer is configured to interrupt once every 1ms, and the tick count variable is increased by 1 when the interrupt occurs. When the previous tick count value of the task differs from the current tick count value by 5, the 5ms task is executed, and so on, thereby realizing task scheduling without an operating system through this frequency division method.

[0101] The resource management unit is used to manage some public resources and function interfaces, so that other layers can call the system resources of the system layer. That is, if other layers need to use system resources, they can directly call some function interfaces of the resource management unit to use system resources; for example: redefinition of variable types, big-endian conversion interface, etc. SYS components are associated with system components. For example: components for monitoring system operation failures, etc.

[0102] See also Fig. 9 In a specific embodiment, the code files of the software system architecture are stored in a hierarchical storage mode; in the hierarchical storage mode, the Library folder is used to store the register library officially provided by the MCU chip for the hardware driver layer to call; the Source folder creates different folders according to each level of the software system architecture and the sub-modules within the level, which are used to store different source code files in a hierarchical manner.

[0103] In the software system architecture, managing the files and file directories of the software code is also an important part. To a certain extent, it can more intuitively see the layering of the current architecture and has certain practicality. At the same time, in the hierarchical storage mode, it can improve the code readability and editability of the software system architecture, thereby reducing the project development cycle and improving work efficiency.

[0104] like Fig. 9 As shown in the figure, when the EmbedSSA architecture supports a single MCU chip core, the Library folder is used to store the register library officially provided by the MCU chip, which is subsequently called by the HDL layer. The Source folder stores content related to the EmbedSSA architecture. Fig. 9 It can be seen that different folders are created under the Source folder according to the hierarchy of the architecture and the sub-modules within the hierarchy, which are used to store different source code files in layers (most of the source code in embedded development is mainly C language files). In addition, in order to better distinguish the levels, the source code files of non-third-party components under each level should use the lowercase of the level as the prefix, for example: the source code files in the HDL layer are named hdl_xxx.c or hdl_xxx.h, and the task source code files of the APL layer and GPAL layer should be named apl_task_xx.c and apl_task_xx.h, as well as gpal_task_xx.c and gpal_task_xx.h.

[0105] In a specific embodiment, the software system architecture supports single-core MCU chips and multi-core MCU chips, and when the software system architecture is extended to a multi-core MCU chip, each MCU chip core runs independently, and the Source folder is jointly managed by the System folder and multiple SubSystem folders. The System folder is used to store content related to starting the multi-core system, and each SubSystem folder creates different folders according to the various levels and sub-modules within the levels of the software system architecture associated with each MCU chip core, which are used to store different source code files in layers.

[0106] See also Fig.10, the EmbedSSA architecture has a certain degree of versatility. For example, when it is expanded to a dual-core MCU chip, the software system System contains two subsystems SubSystem, corresponding to the two cores of the MCU chip (CPU Core 0 and CPU Core 1), and each chip core can run independently. When the main system System starts, the first core (CPU Core 0) will be turned on, and then the first core will start other cores. Therefore, the EmbedSSA architecture can be used separately in each subsystem SubSystem, and software development at different levels can still refer to the EmbedSSA of the single core, so that the architecture can still be used in large or medium-to-large projects.

[0107] When the architecture is extended to a multi-core system, the original software code file management method also needs to be modified, as shown in Figure 11. That is, based on the original Source folder, the System folder and multiple SubSystem folders are used for joint management. The System folder stores the content related to starting the multi-core system, and each SubSystem folder stores the content related to the current chip core separately according to the original file regulations of EmbedSSA.

[0108] The embedded software system architecture provided by the present invention is highly versatile and can be widely used in embedded devices based on MCU chips in the embedded field. The following are specific examples of the present invention applied to embedded devices in different fields:

[0109] See also Fig.12 This example is a medium-to-large project in the field of automotive electronics. It is applied to the power domain controller, adopts a multi-core MCU (using RTOS) and Simulink modeling development method, and uses the EmbedSSA software system architecture of the present invention to realize vehicle control and battery management functions.

[0110] See also Fig.13 This example is a small and medium-sized project in the field of industrial electronics. It is applied to a four-station turntable controller. It adopts a single-core MCU (using RTOS) and a non-modeled development method (manually implementing application layer logic), and uses the EmbedSSA software system architecture of the present invention to realize the control function of the four-station turntable on the industrial automation assembly line.

[0111] See also Fig.14This example is a small project in the field of medical electronics. It is applied to blood oximeter equipment. It adopts a single-core MCU (without RTOS) and a non-modeled development approach (manually implementing application layer logic), and uses the EmbedSSA software system architecture of the present invention to realize the collection, calculation and display of human blood oxygen.

[0112] An embedded software system architecture provided by the present invention has the following advantages:

[0113] 1. The hierarchical architecture and implementation are simple, and the design cost is low;

[0114] 2. Small memory footprint, can be applied to resource-constrained MCU chips;

[0115] 3. The code is easy to read, without using a complicated implementation process, and the interface is encapsulated in a unified format for easy porting;

[0116] 4. Strong versatility, theoretically can be applied to embedded devices based on MCU chips in different embedded fields;

[0117] 5. Strong scalability, can be tailored as needed, and can also be expanded to multi-core MCU chips.

[0118] See also Fig.15 and Fig.16 The second aspect of the present application provides an application method of an embedded software system architecture, comprising:

[0119] Step 101, obtain system design requirements of the software system architecture, and create a requirement planning table for each layer of the software system architecture.

[0120] It should be noted that at the beginning of project development, the requirements must be clearly defined, that is, what resources in the chip are used, so that it is easy to expand or tailor the functions in the EmbedSSA software system architecture. For example, assuming that the system requirements are: single-core MCU, use of RTOS (need to monitor system abnormalities), use of TIM timer peripherals and CAN peripherals, support for UDS diagnosis and CCP calibration, and application layer model code generated by Simulink, the overall plan created is shown in Table 3:

[0121] Table 3 Demand planning table

[0122]

[0123] For ease of understanding, the subsequent execution steps are further explained using this example.

[0124] Step 102, based on the demand planning table, create tasks associated with the application layer and the general peripheral access layer through the operating system management unit and implement scheduling operation, configure the SYS component and the management resource management unit to complete the configuration of the system layer.

[0125] It is understandable that configuring the system layer is the most basic step in building the EmbedSSA software system architecture, that is, the basic engineering, which implements the main function entry and uniformly manages the tasks in the GPAL layer and the APL layer (creates and runs tasks) to provide systematic services. In the example, it is mainly divided into the register description code and FreeRTOS operating system provided by the transplant chip. After the debugging and running are passed, the Cm_BackTrace system fault tracking component is added for system fault tracking and analysis. When the RMU is not in use, it can be left blank (i.e., trimmed).

[0126] Step 103, based on the demand planning table, initialize and configure chip registers and related peripherals, implement the driver interface, and realize the hardware driver layer.

[0127] It should be noted that the hardware driver layer is mainly used to drive the chip and chip peripherals, and implements the initialization of CAN peripherals, sending and receiving, interrupt service functions, and fault handling related interfaces through chip registers, and provides them to the GPAL layer for calling. At the same time, the callback function interface of GIF in the GPAL layer is called back in the interrupt service function of CAN. In particular, the callback interface position needs to be reserved, and it can be added when executing subsequent steps.

[0128] Step 104 , based on the demand planning table, divide and run the second task associated with the underlying code, and encapsulate the function interface associated with the second task to implement a universal peripheral access layer.

[0129] It should be noted that in the example, the GPAL layer mainly implements two second tasks (GPAL_Task1 and GPAL_Task2) that belong only to the underlying code. These two tasks are mainly responsible for periodically calling the MainFunction interface of the UDS and CCP protocol stacks encapsulated by the FLU in the FML layer. This part of the interface is used to maintain the internal state machine of the protocol stack so that the protocol stack can work normally.

[0130] GIF is responsible for encapsulating the HDL layer interface, such as the CAN peripheral transmission interface. In addition, since the CAN peripheral reception requires high real-time performance and the received CAN message data needs to be transmitted to the UDS and CCP protocol stacks, it is necessary to call back the UDS and CCP receiving functions of the FLU in the FML layer in GIF to connect it with the HDL layer, so the callback function will eventually be executed in the interrupt service function of the HDL layer. Similarly, the callback interface position needs to be reserved and added when executing subsequent steps.

[0131] Step 105 , based on the demand planning table, transplant related functional modules and encapsulate interfaces associated with the functional modules to realize the functional module layer.

[0132] It is understandable that the FML layer is mainly used to implement software functions. The UDS protocol stack and the CCP protocol stack can be transplanted into the FML component first, and then the GIF interface in the GPAL layer and the interface in the FML component can be combined to implement different functions, such as: diagnostic message sending, calibration message sending, and CAN bus fault detection and clearing functions. After these functions are implemented and encapsulated, they can be provided to the upper and lower layers for calling.

[0133] Step 106, based on the demand planning table, encapsulate the interface of the bottom layer code according to a preset format, and reserve an interface position linking the interface of the bottom layer code and the code interface of the application layer.

[0134] It should be noted that the main function of the CLL layer is to link the functional interface in FML with the code interface of the APL layer, that is, to match the variables used in APL or the variables generated by the model with the underlying interface, and to encapsulate the new interface formed after the link and the interface of the underlying code in a unified format, so as to provide them to the APL layer for use. At this time, if the APL layer has not yet been implemented, the corresponding interface should be reserved.

[0135] Step 107, based on the demand planning table, generate application layer code, divide and run the first task, and perform modeling design to realize the application layer.

[0136] It is understandable that the code of the APL layer can be developed independently from the underlying code to reduce the coupling between layers. In the example, two tasks (APL_Task1 and APL_Task2) and two business logic units (BLU1 and BLU2) are created, of which APL_Task1 and APL_Task2 are run and scheduled by the System layer, and different BLUs are executed within the tasks.

[0137] BLU can be generated by MATLAB's Simulink model, which implements the logic of when and under what conditions diagnosis or calibration can be triggered. In the field of automotive electronics, the BLU part is generally developed by the OEM (vehicle manufacturer) during the actual development process, so customers do not need to know how the underlying code is implemented. They only need to link some variables and interfaces to the CCL layer, and then call the interface with a unified naming format in the CLL layer to reduce the project development cycle.

[0138] Step 108, adjusting the link relationship between the interface of the bottom code and the code interface of the application layer according to the application code to form a new interface, and encapsulating the new interface according to a preset format to implement a code link layer.

[0139] It is understandable that after the APL layer model has been implemented, after the corresponding application layer code is generated, it is necessary to readjust the CLL layer code link according to the actual variables and interfaces of the application layer to ensure that the application layer and the bottom layer are connected.

[0140] The present invention provides an application method for an embedded software system architecture, which has a simple implementation process, strong scalability and portability, can be tailored or modified according to actual software system architecture requirements, can be expanded to multi-core MCU chips, has strong versatility, and can theoretically be applied to embedded devices based on MCU chips in various embedded fields.

[0141] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0142] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0143] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0144] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0145] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An embedded software system architecture, characterized in that: include: The system layers and levels are arranged from top to bottom in the order of application layer, code link layer, function module layer, general peripheral access layer and hardware driver layer; The system layer exchanges information with other layers to provide system services; The application layer is used to divide the first task according to the preset task scheduling conditions and run the first task; The application layer code is separated from the underlying code; The code link layer is used to link the code of the application layer and the underlying code, and encapsulate the linked interface and the interface of the underlying code according to a unified naming format; The functional module layer is used to manage functional components and lower layer interfaces; The universal peripheral access layer is used to divide and run the second task associated with the underlying code according to the preset task scheduling conditions; The hardware driver layer is used to drive the chip and chip peripherals, and encapsulates the driver interface and provides it to the upper layer and the system layer for use.

2. An embedded software system architecture according to claim 1, characterized in that: The application layer includes an application layer task unit and a business logic unit; The application layer task unit is used to divide the first task according to a preset task scheduling condition; The business logic unit is used to implement the logic code of the application layer and at the same time serve as the executor of the first task, and to connect with the code link layer through variables and function interfaces.

3. An embedded software system architecture according to claim 1, characterized in that: The code link layer includes a code link unit and an encapsulation unit; The code linking unit is used to assign values ​​and implement specific variables or function interfaces required by the application layer, and link the interface of the code of the application layer with the interface of the underlying code; The encapsulation unit is used to encapsulate the linked interface and the interface of the underlying code according to a unified naming format.

4. The embedded software system architecture according to claim 1, characterized in that: The functional module layer includes FML components and functional logic units; The FML component is associated with the functional component and supports any operation mode of adding, deleting and combining with a third-party functional component package; The functional logic unit is used to implement functions and encapsulate interfaces of the GIF interface of the universal peripheral access layer and the interface of the FML component.

5. The embedded software system architecture according to claim 1, characterized in that: The universal peripheral access layer includes a universal peripheral access layer task unit and a universal peripheral access layer interface; The general peripheral access layer task unit is used to divide and run the second task associated with the bottom layer code according to the preset task scheduling conditions, and run the functional tasks that need to be processed periodically at the functional module layer; The universal peripheral access layer interface is used to encapsulate the function interface associated with the second task, and encapsulates the interface of the functional module layer in the form of a callback function to be responsible for the interface transmission between the functional module layer and the hardware driver layer.

6. The embedded software system architecture according to claim 1, characterized in that: The hardware driver layer is specifically used to initialize and configure chip registers, start the peripheral functions of the chip, and encapsulate the driver interface for use by the upper layer and the system layer; and use the system resources of the system layer according to usage requirements.

7. The embedded software system architecture according to claim 1, characterized in that: The system layer includes an operating system management unit, a resource management unit and a SYS component; The operating system management unit is used to create and schedule system tasks and provide system services through the operating system when the operating system is deployed; When no operating system is deployed, the scheduling of system tasks is simulated through the chip timer; The resource management unit is used to manage some public resources and function interfaces; The SYS component is associated with a systemic component.

8. An embedded software system architecture according to claim 1, characterized in that: The code files of the software system architecture are stored in a hierarchical storage mode; In the hierarchical storage mode, the Library folder is used to store the register library officially provided by the MCU chip for the hardware driver layer to call; the Source folder creates different folders according to the various levels of the software system architecture and the sub-modules within the levels to store different source code files in layers.

9. An embedded software system architecture according to claim 8, characterized in that: The software system architecture supports single-core MCU chips and multi-core MCU chips, and when the software system architecture is extended to multi-core MCU chips, each MCU chip core runs independently, and the Source folder is jointly managed by the System folder and multiple SubSystem folders, and the System folder is used to store content related to starting the multi-core system; Each SubSystem folder is created according to the different levels and sub-modules within the levels of the software system architecture associated with each MCU chip core, and is used to store different source code files in layers.

10. An application method of an embedded software system architecture, characterized in that: include: Obtain the system design requirements for the software system architecture and create a demand planning table for each layer of the system architecture; Based on the demand planning table, the operating system management unit is used to create tasks associated with the application layer and the general peripheral access layer and implement scheduling operations, and the SYS components and management resource management unit are configured to complete the configuration of the system layer; Based on the demand planning table, initialize and configure chip registers and related peripherals, implement the driver interface, and realize the hardware driver layer; Based on the demand planning table, divide and run the second task associated with the underlying code, and encapsulate the function interface associated with the second task to realize the universal peripheral access layer; Based on the demand planning table, transplant relevant functional modules and encapsulate interfaces associated with the functional modules to realize the functional module layer; Based on the demand planning table, encapsulate the interface of the underlying code according to a preset format, and reserve an interface position for linking the interface of the underlying code and the code interface of the application layer; Based on the demand planning table, generate application layer code, divide and run the first task, and perform modeling design to implement the application layer; The link relationship between the interface of the bottom layer code and the code interface of the application layer is adjusted according to the application code to form a new interface, and the new interface is encapsulated according to a preset format to realize a code link layer.

Images