Embedded software system architecture and application method

Abstract

The present invention discloses an embedded software system architecture and 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. The system layer interacts with other layers to provide systematic services; the application layer is used to divide the first task and run the first task; the code link layer is used to link the code of the application layer and the underlying code; the function module layer is used to manage functional components and lower-layer interfaces; the general peripheral access layer is used to divide and run the second task associated with the underlying code; the hardware driver layer is used to drive chips and chip peripherals and encapsulate the driver interface. In the present invention, the architecture of each layer is simple and each layer performs different functions, the implementation cost is low, and the design can be tailored and expanded according to the actual system architecture design requirements, and cross-domain applications can be realized, with strong portability and versatility.

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 microcontrollers (MCUs) are also widely used in people's lives, such as smart homes and wearables, medical devices, 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 traditional embedded software development, most projects simply divide the software into two parts: the application (APP) and the board support package (BSP). However, this layering is too general, making it difficult to cope with increasingly complex applications during actual development. In addition, the code is highly coupled, making it difficult to port to other projects.

[0004] Modern smart cars use numerous embedded MCUs. To standardize the development of these devices, Germany proposed the OSEK standard, short for Open Systems and the Corresponding Interfaces for Automotive Electronics. While OSEK has improved the portability and scalability of automotive electronics software, it lacks universality and is not applicable to other MCU embedded applications, such as consumer and industrial electronics. With the advancement of automobiles, OSEK no longer meets existing development needs. Consequently, several German automotive consortiums have proposed a new architecture, the Automotive Open System Architecture (AUTOSAR), of which the MCU-related AUTOSAR Classic Platform is the AUTOSAR Classic Platform. AUTOSAR utilizes a layered and modular design, facilitating software development for automotive electronics. While the standard is open, its implementation is complex. Companies seeking to use AUTOSAR must purchase the software or implement it themselves, resulting in high acquisition and implementation costs. Therefore, AUTOSAR is not suitable for consumer electronics and other applications. Furthermore, it requires significant chip resources, making it unsuitable for resource-constrained MCUs and resulting in 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] A 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, arranged 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] Furthermore, 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 the preset task scheduling conditions;

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

[0017] Furthermore, 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 application layer code 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] Furthermore, 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 third-party functional component packages;

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

[0023] Furthermore, 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 uses a callback function to encapsulate the interface of the functional module layer 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] Furthermore, 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 an operating system is deployed; when no operating system is deployed, the operating system management unit simulates the scheduling of system tasks 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 systemic components.

[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 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. 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 of 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 operations, 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 thus realize the hardware driver layer;

[0038] Based on the demand planning table, dividing and running a second task associated with the underlying code, and encapsulating a function interface associated with the second task to implement a 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 in a preset format, and reserve the 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 model design to implement the application layer;

[0042] The link relationship between the interface of the bottom 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 the 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 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 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 according to a unified naming format; the functional module layer is used to manage functional components and lower-level interfaces; the general peripheral access layer is used to divide and run the second task associated with the underlying code according to preset task scheduling conditions; the hardware driver layer is used to drive chips and chip peripherals, and encapsulate the driver interface for use by the upper layer and the system layer.

[0046] In the present invention, each layer of the software system architecture is simple in architecture and has a low implementation cost, and each layer 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 following briefly introduces the drawings required for use in the embodiments or the description of the prior art. 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 any creative work.

[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 by 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 universal 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] Figure 9 A tree diagram of the file directory provided for this application;

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

[0058] Figure 11 A tree diagram describing the multi-core system file directory provided by this application;

[0059] Figure 12 This is a diagram describing an example of the embedded software system architecture provided in this application being applied in the automotive electronics field;

[0060] Figure 13 This is a diagram describing an example of the embedded software system architecture provided in this application being applied in the field of industrial electronics;

[0061] Figure 14 This is a diagram describing an example of the embedded software system architecture provided in this application being applied in the field of medical electronics;

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

[0063] Figure 16 This is 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 making 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) and an application layer (Application Layer, APL), a code link layer (Code Link Layer, CLL), a functional module layer (FML), a general peripheral access layer (GPAL) and a hardware driver layer (HDL).

[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, universality and maintainability.

[0068] The basic design principles include: 1) Layered design: Divide the system into multiple layers, with each layer responsible for different functions, but the number of 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 used to implement a specific function or business, in order 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 tailor unused functions. 5) Versatility: The system should be applicable to different domain scenarios as much as possible, that is, it should be portable to other projects. 6) Maintainability: The system design should be easy to read, understand, modify, and expand, so that the system can continue to evolve and be maintained.

[0069] In the present invention, each layer plays a different role and implements specific functions or services, 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 and execute the first tasks according to preset task scheduling conditions. The application layer can execute the first tasks of various practical applications. The preset task scheduling conditions can be the task execution period or the specific functional category of the task. At the same time, the application layer code is separated from the underlying code, which can reduce the interdependence between the various layers in the system architecture and enhance maintainability.

[0072] The code linking layer links the application layer code with the underlying code and encapsulates the linked interfaces and the underlying code's interfaces using a unified naming format. In this invention, the code linking layer primarily connects the upper and lower layers of code (the application layer code and the underlying code). It also encapsulates the linked interfaces and the underlying code's interfaces into a unified API (Application Programming Interface) naming format, making them easier to port to other projects and thus reducing project development cycles.

[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 part of the system architecture and ensure the scalability of software functions.

[0074] The general peripheral access layer is used to divide and run secondary tasks associated with the underlying code according to preset task scheduling conditions. The general peripheral access layer is also used to execute various tasks, but the tasks executed are only related to the underlying code and are different and separate from the tasks of the APL layer. This allows the application layer to not need to care about how the underlying tasks are executed, thus achieving decoupling between the application layer and the underlying code. The preset task scheduling conditions can also be used to divide different secondary tasks according to execution cycle or peripheral function.

[0075] The hardware driver layer is responsible for driving the chip and its peripherals, encapsulating the driver interface and providing it to the upper and system layers. The hardware driver layer is responsible for connecting to the hardware registers of the chip's peripherals to enable the chip's peripheral functions and ensure normal operation.

[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 and 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, supporting 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 layer of the software system architecture performs different functions, and each layer can also be divided into multiple independent modules. The following is a further detailed description of each layer of the software system architecture:

[0078] See also Figure 3 In one specific embodiment, the application layer includes an application layer task unit (APL Task Unit, ATU) and a business logic unit (BLU). The application layer task unit is used to divide the first task according to preset task scheduling conditions. The business logic unit is used to implement the application layer's logic code and simultaneously serves as the executor of the first task, interfacing with the code link layer through variable and function interfaces. The ATU can be divided into multiple first tasks based on execution cycles, such as 5ms tasks, 10ms tasks, and 50ms tasks, or divided according to specific functions, such as vehicle lighting control tasks and wiper control tasks. The task executor within the ATU is composed of one or more BLUs, whose internal task descriptions are 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 logical functions of the code manually implemented by engineers (non-modeling development), and also supports the generation of logical function code using MATLAB modeling development (using the Simulink tool in MATLAB to generate C language code). The implementation method of its logical 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 to establish variable 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 realize the application layer function control of 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 in the APL layer, and the APL layer will eventually call the API_XxxGetValueFunction() and API_XxxSetValueFunction() interfaces. APP_U.XxxValue and APP_Y.XxxValue are connected to the underlying FML layer, thereby implementing value transfer in the code link layer to connect the upper and lower code layers. If the FML layer interface does not need to use APL layer variables, 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 ultimately adopt a unified naming style (prefixed with API), namely API_Xxx, to facilitate porting to other projects, 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 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 there are sufficient chip memory resources). During the software development process, engineers often use self-developed or third-party functional component packages, such as the UDS protocol stack and the LwIP protocol stack, and then combine these components to jointly implement certain functions of the software. 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 uses FML Component 1, that is, it controls FML Component 1 and provides interfaces to the upper and lower layers; FLU 3 calls one or more GIF interfaces of the lower GPAL to form a sub-function and provides it to the upper layer.

[0089] In addition to implementing sub-functions, FLU also serves the purpose of encapsulating interfaces. This primarily standardizes the interface format of the architecture, making it easier to distinguish which layer of the interface is being called, reducing the coupling between the upper and lower layers and avoiding cross-layer calls. Furthermore, when 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's important to note that the GPAL layer has two main functions: 1. It runs secondary tasks that belong only to the underlying code. These tasks are separate from the APL layer and remain invisible to customers unless the underlying source code is open source. Even if the APL layer's primary task is empty, the underlying code can still run normally. 2. It serves as a bridge between FML and HDL. If certain peripheral drivers in the HDL layer don't need to be executed within a GPAL task, they can be formatted and directly provided to the FML layer for use, and the FML layer's interfaces can also be called.

[0092] Specifically, the GTU is similar to the ATU in the APL layer, similarly scheduled by the System layer and similarly organized into different tasks based on cycle time or peripheral function. It executes peripheral tasks in the underlying driver that require periodic processing, such as analog voltage acquisition (ADC peripheral task), which periodically updates and converts voltage values ​​and stores them. When needed by the upper layer, it can simply call the analog voltage acquisition function interface in the GIF. The application layer does not need to be concerned with the execution of the underlying tasks, thus decoupling the application layer from the underlying code. Furthermore, the GTU executes functions in the FML layer that require periodic processing, such as the UDS protocol stack for vehicle diagnostics, which contains an internal state machine that executes periodically to handle different situations. Because this component is low-level, it should not be placed in the APL layer but rather in the GPAL layer. Table 2 shows the code running within the GPAL task.

[0093] Table 2 GPAL task internal description example

[0094]

[0095] In actual development, in addition to cyclically running peripherals, some peripherals require a high degree of real-time response, making them less suitable for cyclical operation within GTU tasks. Therefore, in addition to the interface encapsulation mentioned above, GIF also includes an interrupt callback interface. To avoid cross-layer calls, the upper-layer interface is encapsulated using a callback function, which is then called by the HDL layer. This is equivalent to renaming the upper-layer interface and placing it within the HDL layer's interrupt service function, thus ensuring the real-time performance of 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 chip's peripheral functions, so that the chip and OS can operate normally; and encapsulate the driver interface for use by the upper layer and 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 enqueuing). At this time, the OS will generate an event notification that a message queue has been enqueued. Then, after the GTU task in the GPAL layer receives the enqueuing event notification, it will be dequeued and the data will be retrieved (event dequeuing).

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

[0099] The operating system management unit is used to create and schedule system tasks and provide system services through the operating system when an operating system is deployed; when no operating system is deployed, the chip timer is used to simulate the scheduling of system tasks;

[0100] For example, when an operating system is deployed, assuming the operating system used in the MCU chip is a hard real-time system (RTOS), such as open-source real-time operating systems like FreeRTOS and RT-Thread, the operating system can be used to create and schedule tasks for the entire software system, as well as provide system services such as semaphores and message queues. When no operating system is deployed, that is, the MCU is bare metal, the chip timer can be used to simulate task scheduling. For example, the chip timer can be configured to interrupt once every 1ms, incrementing the tick count variable by 1 upon interruption. When the difference between the previous task's tick count and the current task count is 5, the 5ms task is executed, and so on. This frequency division method can achieve task scheduling without an operating system.

[0101] The resource management unit manages some public resources and function interfaces, facilitating other layers to access system resources. This means that if other layers require system resources, they can directly call some of the resource management unit's function interfaces to access them. Examples include redefining variable types and endian conversion interfaces. The SYS component is associated with systemic components, such as those that monitor system failures.

[0102] See also Figure 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] Managing code files and directories is a crucial part of software system architecture. It provides a more intuitive view of the current architecture's layering, which is quite practical. Furthermore, a hierarchical storage model improves the readability and editability of the software system's code, thereby shortening project development cycles and improving work efficiency.

[0104] like Figure 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. Figure 9 As you can see, the Source folder creates different folders based on the architecture's hierarchy and submodules within each hierarchy, used to store different source code files (most source code in embedded development is in C). Furthermore, to better distinguish between the hierarchies, the source code files for non-third-party components at each level should be prefixed with the lowercase version of that level. For example, source code files at the HDL layer are named hdl_xxx.c or hdl_xxx.h, while task source code files at the APL and GPAL layers should be named apl_task_xx.c and apl_task_xx.h, respectively, 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 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. 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.

[0106] See also Figure 10The EmbedSSA architecture has a certain degree of versatility. For example, when expanded to a dual-core MCU chip, the software system "System" includes two subsystems, 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) is enabled, which then starts the other cores. Therefore, the EmbedSSA architecture can be used independently within each subsystem. Software development at different levels can still refer to the EmbedSSA architecture for single-core development, making this architecture applicable to large and 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, a 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 applied to 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 Figure 12 This example is a medium-to-large project in the automotive electronics field. It is applied to the power domain controller and adopts a multi-core MCU (using RTOS) and Simulink modeling development approach. It also uses the EmbedSSA software system architecture of the present invention to realize vehicle control and battery management functions.

[0110] See also Figure 13 This example is a small-to-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-model development approach (manually implementing application layer logic). It also 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 Figure 14This example is a small project in the field of medical electronics, which is applied to oximeter equipment. It adopts a single-core MCU (without using RTOS) and a non-model development approach (manually implementing application layer logic). It also uses the EmbedSSA software system architecture of the present invention to realize functions such as collecting, calculating, and displaying human blood oxygen.

[0112] The 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. It has strong versatility and can theoretically 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 Figure 15 and Figure 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 for the software system architecture and create a requirement planning table for each layer of the software system architecture.

[0120] It's important to note that at the beginning of project development, it's crucial to clearly define the requirements—that is, the resources within the chip that will be used—to facilitate the expansion or tailoring of the functionality within the EmbedSSA software system architecture. For example, assuming the system requirements are: a single-core MCU, an RTOS (needing to monitor system anomalies), TIM and CAN peripherals, support for UDS diagnostics and CCP calibration, and application-layer model code generated by Simulink, the overall plan is shown in Table 3:

[0121] Table 3 Demand planning table

[0122]

[0123] To facilitate understanding, the subsequent execution steps are further explained using this example.

[0124] Step 102 : Based on the demand planning table, tasks associated with the application layer and the general peripheral access layer are created and scheduled through the operating system management unit, and the SYS components and the management resource management unit are configured to complete the configuration of the system layer.

[0125] It's understandable that configuring the system layer is the most fundamental step in building the EmbedSSA software system architecture, namely, the foundational engineering. This involves implementing the main function entry point and uniformly managing tasks (creating and running tasks) in the GPAL and APL layers to provide system services. In this example, this primarily involves porting the register description code provided by the chip and the FreeRTOS operating system. After successful debugging, the Cm_BackTrace system fault tracing component is added for system fault tracing and analysis. The RMU can be left blank (i.e., cropped) when not in use.

[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 primarily drives the chip and its peripherals. It implements CAN peripheral initialization, sending and receiving, interrupt service functions, and fault handling through chip registers, providing these interfaces to the GPAL layer. It also calls the GIF callback function interface in the GPAL layer into the CAN interrupt service function. In particular, a location for the callback interface must be reserved so that it can be added in 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] The GIF is responsible for encapsulating HDL-level interfaces, such as the CAN peripheral's transmit interface. Furthermore, because CAN peripheral reception requires high real-time performance and the need to transmit received CAN message data to the UDS and CCP protocol stacks, the GIF calls back the FLU's UDS and CCP receive functions in the FML layer to connect them to the HDL layer. This callback function is ultimately executed in the HDL-level interrupt service function. Similarly, a callback interface location must be reserved for 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's understandable that the FML layer is primarily used to implement software functions. You can first port the UDS and CCP protocol stacks to the FML component, then combine the GIF interface in the GPAL layer with the interface in the FML component to implement different functions, such as sending diagnostic messages, sending calibration messages, and detecting and clearing CAN bus faults. Once these functions are implemented and encapsulated, they can be made available to upper and lower layers for invocation.

[0133] Step 106: Based on the demand planning table, encapsulate the interface of the underlying code in a preset format, and reserve an interface position for linking the interface of the underlying code and the code interface of the application layer.

[0134] It should be noted that the CLL layer's primary function is to link the functional interfaces in FML with the code interfaces in the APL layer. This means that variables used in APL or generated by the model correspond to the underlying interfaces. The newly linked interfaces and the underlying code interfaces are then packaged in a unified format for use by the APL layer. If the APL layer is not yet implemented, the corresponding interfaces 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 implement the application layer.

[0136] It is understandable that the APL layer code 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. APL_Task1 and APL_Task2 are run and scheduled by the System layer, and different BLUs are executed within the tasks.

[0137] BLUs can be generated from MATLAB's Simulink model, implementing logic that specifies when and under what conditions diagnostics or calibrations are triggered. In the automotive electronics field, BLU development is typically performed by the OEM (original vehicle manufacturer). Therefore, customers do not need to understand the underlying code implementation; they simply link variables and interfaces to the CCL layer and then call the CLL layer's uniformly named interfaces, reducing project development cycles.

[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 with a simple implementation process, strong scalability and portability. It can be tailored or modified according to the actual software system architecture requirements and can be expanded to multi-core MCU chips. It 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 will 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 this 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 merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, 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 separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0144] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or 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 above embodiments, those skilled in the art should understand that the technical solutions described in the above embodiments can still be modified, or some of the technical features thereof can 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 layer and the layers 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 encapsulate the driver interface and provide it to the upper layer and the system layer for use; 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 uses a callback function to encapsulate the interface of the functional module layer to be responsible for the interface transmission between the functional module layer and the hardware driver layer.

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 the preset task scheduling conditions; The business logic unit is used to implement the logic code of the application layer and serve as the executor of the first task, and to connect with the code link layer through variables and function interfaces.

3. The embedded software system architecture according to claim 1, wherein: 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 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.

4. The embedded software system architecture according to claim 1, wherein: 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 third-party functional component packages; The functional logic unit is used to implement functions and perform interface encapsulation on 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, wherein: The hardware driver layer is specifically used to initialize and configure chip registers, start the chip's peripheral functions, and encapsulate the driver interface for use by the upper layer and system layer; and use the system resources of the system layer according to usage requirements.

6. The embedded software system architecture according to claim 1, wherein: 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 system task scheduling 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 systemic components.

7. The 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.

8. An embedded software system architecture according to claim 7, characterized in that: The software system architecture supports single-core MCU chips and multi-core MCU chips. When the software system architecture is extended to multi-core MCU chips, each MCU chip core runs independently. 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 is created according to the different levels and sub-modules within the software system architecture associated with each MCU chip core, and is used to store different source code files in layers.

9. An application method of an embedded software system architecture, characterized in that: include: Obtain the system design requirements of the software system architecture and create a demand planning table for each layer of the system architecture; 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 operations, configure SYS components and manage resource management units 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 thus realize the hardware driver layer; Based on the demand planning table, dividing and running a second task associated with the underlying code, and encapsulating a function interface associated with the second task to implement a universal peripheral access layer; the universal peripheral access layer includes a universal peripheral access layer task unit and a universal peripheral access layer interface; The universal peripheral access layer task unit is used to divide and run the second task associated with the underlying code according to the preset task scheduling conditions, and run the functional tasks that need to be processed periodically by the functional module layer; the universal 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; 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 in a preset format, and reserve the 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 model 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 layer code to form a new interface, and the new interface is encapsulated according to a preset format to realize the code link layer.

Images