Construction method and device of software architecture, electronic equipment and medium

Abstract

Embodiments of the present application provide a software architecture construction method and device, electronic equipment and medium, and relate to the technical field of computers. The method comprises: determining the design requirements of the target software system, the design requirements comprising at least functional requirement information and functional safety requirements; analyzing and classifying the functional requirement information and the functional safety requirements to determine the category and safety level of the functions; and determining the software modules in the target software system according to the category and / or safety level of the functions. The method divides software modules according to functional requirements, thereby constructing a new software architecture, and according to the granularity of the software architecture management refined according to functions, the isolation requirements of functional safety can be met, and mutual interference of mutually independent function faults can be avoided.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and medium for constructing a software architecture. Background Technology

[0002] Functional safety refers to the use of appropriate engineering measures to avoid or mitigate safety risks caused by failures in electrical / electronic (E / E) systems. It is the process of identifying potential hazards, assessing risks, and taking measures to control or eliminate these risks. For the functional safety of automotive electrical / electronic systems, the International Organization for Standardization (ISO) published the ISO 26262 standard – Road Vehicles – Functional Safety. The ISO 26262 standard introduces the concept of automotive safety integrity level (ASIL), classifying the safety of automotive systems into five levels: QM, ASILA, ASIL B, ASILC, and ASILD. ASILD represents the highest level of safety integrity.

[0003] To achieve the functions of automotive electronic and electrical systems, current methods stack numerous electronic control units (ECUs) to deploy applications with different safety levels on different hardware devices, thus achieving resource isolation. In this approach, applications with different safety levels are essentially executed by separate devices. While resource isolation is achieved, this requires extensive hardware stacking, and communication latency between applications with different safety levels is relatively high. With the development of electronic and electrical system architectures, the number of ECUs in a vehicle is decreasing, while each ECU carries more and more diverse functions. The functional safety levels of the applications carried by each ECU are also becoming more varied. Managing the applications carried by each ECU according to the existing software architecture may reduce system reliability (for example, management according to the existing software architecture may lead to illegal software read / write operations, non-operational logic, and ultimately software failures). Summary of the Invention

[0004] To solve the above-mentioned technical problems, or at least partially solve the above-mentioned technical problems, embodiments of the present invention provide a method, apparatus, electronic device and medium for constructing a software architecture.

[0005] In a first aspect, embodiments of the present invention provide a method for constructing a software architecture, used for architectural design of a target software system, the method comprising:

[0006] Determine the design requirements of the target software system, which include at least functional requirements and functional safety requirements;

[0007] The functional requirements information and functional safety requirements are analyzed and classified to determine the category and security level of the function.

[0008] The software modules in the target software system are determined by using the category and / or security level of the function as the granularity.

[0009] Optionally, determining the software modules in the target software system based on the category and / or security level of the function includes:

[0010] Deploying functions with the same security level and category into the same software module, deploying functions with different security levels but the same category into different software modules, and deploying functions with the same security level but different categories into different software modules.

[0011] Optionally, the categories of the functions include: application layer class, underlying class, and adaptation layer class; each of the application layer class, the underlying class, and the adaptation layer class includes multiple subclasses;

[0012] The step of determining the software modules in the target software system based on the category and / or security level of the function includes:

[0013] The software modules in the target software system are determined by using the functions and / or security levels corresponding to the multiple subclasses included in the application layer class, the underlying class, and the adaptation layer class as the granularity of division.

[0014] Optionally, the category of the function includes the category of communication protocol; the step of determining the software modules in the target software system based on the category of the function and / or the security level includes:

[0015] Deploy the protocol stacks corresponding to different types of communication protocols into different software modules.

[0016] Optionally, the communication protocol categories include: private controller area network bus protocol, public controller area network bus protocol, and Ethernet protocol;

[0017] The deployment of protocol stacks corresponding to different types of communication protocols into different software modules includes:

[0018] The protocol stacks corresponding to the private controller LAN bus protocol, the public controller LAN bus protocol, and the Ethernet protocol are deployed in different software modules.

[0019] Optionally, deploying the protocol stacks corresponding to different categories of communication protocols into different software modules includes:

[0020] If there are functions that require the use of the Private Controller Area Network (PCN) Bus Protocol, then deploy the PCN Bus Protocol and the functions into the same software module.

[0021] Optionally, the method further includes: mapping the relevant data of each software module to a fixed physical address space in memory; wherein the relevant data includes one or more of the software module's code, private variables, shared variables, and scalar values.

[0022] Optionally, mapping the relevant data of each software module to a fixed physical address space in memory includes one or more of the following:

[0023] The code of all the software modules is physically located in contiguous blocks of memory;

[0024] The shared variables of all the software modules are physically located in contiguous memory.

[0025] The calibrated values ​​of all the software modules are located in contiguous physical addresses in memory;

[0026] The private variables of all the software modules described are not located at contiguous physical addresses in memory.

[0027] Optionally, mapping the relevant data of each software module to a fixed physical address space in memory includes one or more of the following:

[0028] The code of all the software modules is physically located in contiguous blocks of memory;

[0029] The shared variables of all the software modules are physically located in contiguous memory.

[0030] The calibrated values ​​of all the software modules are located in contiguous physical addresses in memory;

[0031] All the private variables of the software modules described are located at contiguous physical addresses in memory.

[0032] Optionally, the method includes: setting permissions for each software module; wherein setting permissions for each software module includes one or more of the following:

[0033] Configure each software module to have permission to execute the code of all software modules;

[0034] Each software module is configured to have read and write permissions for its own private and shared variables;

[0035] Configure each software module to have read-only access to shared variables of other software modules;

[0036] Configure each software module to have read-only permissions for all calibration values.

[0037] Optionally, the method further includes: setting a global shared area in memory, and configuring software modules with specified functions to have read and write permissions to the global shared area.

[0038] Optionally, the method further includes: in response to detecting a faulty software module, restarting the faulty software module, and providing specified information to the software module receiving the output of the faulty software module.

[0039] Secondly, embodiments of the present invention provide a software architecture construction apparatus for designing the architecture of a target software system, the apparatus comprising:

[0040] A determination module is used to determine the design requirements of the target software system, wherein the design requirements include at least functional requirements information and functional safety requirements;

[0041] The analysis module is used to parse and classify the functional requirement information and the functional safety requirements to determine the category and security level of the function;

[0042] The segmentation module is used to determine the software modules in the target software system based on the category and / or security level of the function.

[0043] Optionally, the partitioning module is further configured to: deploy functions of the same security level and the same category into the same software module, deploy functions of different security levels and the same category into different software modules, and deploy functions of the same security level and different categories into different software modules.

[0044] Optionally, the categories of the functions include: application layer class, underlying class, and adaptation layer class; each of the application layer class, the underlying class, and the adaptation layer class includes multiple subclasses;

[0045] The partitioning module is further configured to: determine the software modules in the target software system based on the functions and / or security levels corresponding to the multiple subclasses included in the application layer class, the underlying class, and the adaptation layer class, using the partitioning granularity.

[0046] Optionally, the categories of the functions include the categories of communication protocols; the partitioning module is also used to: deploy the protocol stacks corresponding to different categories of communication protocols into different software modules.

[0047] Optionally, the communication protocol categories include: private controller area network bus protocol, public controller area network bus protocol, and Ethernet protocol;

[0048] The partitioning module is also used to deploy the protocol stacks corresponding to the private controller LAN bus protocol, the public controller LAN bus protocol, and the Ethernet protocol to different software modules.

[0049] Optionally, the partitioning module is further configured to: if there is a function that requires the use of the private controller local area network bus protocol, then deploy the private controller local area network bus protocol and the function into the same software module.

[0050] Optionally, the apparatus further includes a mapping module for: mapping relevant data of each software module to a fixed physical address space in memory; wherein the relevant data includes one or more of the software module's code, private variables, shared variables, and scalar values.

[0051] Optionally, the mapping module is further configured to: have all the code of the software modules in contiguous physical addresses in memory; have all the shared variables of the software modules in contiguous physical addresses in memory; have all the scalar values ​​of the software modules in contiguous physical addresses in memory; and have all the private variables of the software modules in non-contiguous physical addresses in memory.

[0052] Optionally, the mapping module is further configured to: ensure that the physical addresses of the code of all the software modules are contiguous in memory; ensure that the physical addresses of the shared variables of all the software modules are contiguous in memory; ensure that the physical addresses of the scalar values ​​of all the software modules are contiguous in memory; and ensure that the physical addresses of the private variables of all the software modules are contiguous in memory.

[0053] Optionally, the device further includes a permission setting module, used to: set the permissions of each software module; wherein setting the permissions of each software module includes one or more of the following: setting each software module to have the permission to execute the code of all software modules; setting each software module to have the permission to read and write its own corresponding private variables and shared variables; setting each software module to have the permission to read only the shared variables corresponding to other software modules; setting each software module to have the permission to read only all calibrated variables.

[0054] Optionally, the permission setting module is further configured to: set a global shared area in memory, and configure software modules with specified functions to have the permission to read and write the global shared area.

[0055] Optionally, the device further includes a fault detection module, configured to: restart the faulty software module in response to detecting a faulty software module, and provide specified information to the software module receiving the output of the faulty software module.

[0056] Thirdly, embodiments of the present invention provide an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor is used to implement the software architecture construction method of any embodiment of the present invention when executing the program stored in the memory.

[0057] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for constructing a software architecture according to any embodiment of the present invention.

[0058] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects:

[0059] This invention provides a method for constructing a software architecture. By analyzing and classifying the functional requirements and functional safety requirements of a target software system, the categories and safety levels of functions are determined. Software modules within the target software system are then identified using these categories and / or functional safety levels as the granularity of division. This method divides software modules according to functional requirements, thereby constructing a new software architecture. By refining the granularity of software architecture management based on functionality, it can meet the isolation requirements of functional safety and prevent crosstalk between independent functional faults. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0061] Figure 1 A flowchart illustrating a method for constructing a software architecture according to an embodiment of the present invention is shown.

[0062] Figure 2 A schematic diagram of a system architecture constructed according to the method provided in embodiments of the present invention is shown;

[0063] Figure 3 A flowchart illustrating a method for constructing a software architecture according to an embodiment of the present invention is shown.

[0064] Figure 4 A schematic diagram of the structure of a software architecture construction apparatus according to an embodiment of the present invention is shown;

[0065] Figure 5A schematic diagram of the structure of an electronic device according to an embodiment of the present invention is shown. Detailed Implementation

[0066] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0067] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0068] Figure 1 A flowchart illustrating a method for constructing a software architecture according to an embodiment of the present invention is shown. This method is used for architectural design of a target software system, which may, for example, be deployed in an vehicle. Figure 1 As shown, the method includes:

[0069] Step S101: Determine the design requirements of the target software system, wherein the design requirements include at least functional requirements information and functional safety requirements.

[0070] Functional requirements information indicates the functions that the target software system needs to implement, such as, but not limited to, functions for driving the vehicle, controlling the vehicle body, software diagnostics, calibration, and communication. Functional safety requirements indicate the safety level of each function implemented by the target software system. For example, the functional safety requirements must comply with the ISO 26262 standard for functional safety of road vehicles.

[0071] Step S102: Analyze and classify the functional requirement information and the functional safety requirements to determine the category and security level of the function.

[0072] Optionally, functional categories include service, driver, and function categories. Services include NVM (Non-Volatile Memory) read / write, diagnostics, and configuration words (a set of data stored on the automotive electronic control unit, usually in the form of a data identifier (DID), used to define and adjust vehicle function configurations; modifying the configuration word can enable, disable, or adjust vehicle functions). Functions include software diagnostics, OS (operating system), ECUMM (ECU Manager, the electronic control unit's status management module), calibration, and communication. Drivers include ADC (Analog to Digital Converter) acquisition, IO (Input / Output) acquisition, and IO drivers. This invention can be implemented by designing the app according to major functional categories or by subcategories.

[0073] Optionally, the functional categories include: application layer classes, underlying layer classes, and adaptation layer classes. Each of the application layer class, underlying layer class, and adaptation layer class includes multiple subclasses. The software modules in the target software system can be determined by the granularity of the functions and / or security levels corresponding to the multiple subclasses included in the application layer class, the underlying layer class, and the adaptation layer class. The application layer refers to the application software (ASW) layer in the automotive electronic system, primarily responsible for implementing specific vehicle functions, such as in-vehicle entertainment systems, body control systems, and engine control systems. ASW is directly related to the vehicle's functional requirements, such as controlling the engine and managing body electronic devices. The underlying layer refers to the basic software (BSW) layer in the automotive electronic system, primarily responsible for providing underlying hardware abstraction and basic services, such as operating systems, communication protocols, and drivers. BSW provides basic functions such as memory management, communication interfaces, and diagnostic services, supporting the operation of ASW. The adaptation layer lies between the application layer and the underlying layer, primarily coupling the application layer and the underlying layer through proxy services.

[0074] Safety levels include, for example, the five levels specified in the ISO-26262 standard for functional safety of road vehicles: QM, ASIL A, ASIL B, ASIL C, and ASIL D. Among them, ASIL D is the highest level of safety integrity.

[0075] The embodiments of the present invention divide the functions required to be implemented by the target software system and the security level of each function. This can decompose the originally complex functional safety development of the vehicle controller and build it according to the divided functions and security levels, which can reduce the development difficulty and improve the development efficiency.

[0076] Step S103: Determine the software module (Application, abbreviated as APP) in the target software system based on the category and / or security level of the function.

[0077] For example, functions with the same security level and category can be deployed in the same software module, functions with different security levels but the same category can be deployed in different software modules, and functions with the same security level but different categories can be deployed in different software modules. That is, in this embodiment, different application services are divided into different software modules; for example, thermal management, body control, and vehicle control are different software modules (i.e., APPs). Functions with the same security level but different security levels have different APPs; for example, vehicle control with a QM security level and vehicle control with an ASILD security level are different APPs, and body control with a QM security level and body control with an ASILD security level are different APPs.

[0078] The software architecture construction method provided in this invention analyzes and classifies the functional requirements and functional safety requirements of the target software system to determine the category and safety level of functions. Using the category and / or functional safety level as the granularity, the method identifies the software modules within the target software system. This method divides software modules according to functional requirements, thereby constructing a new software architecture. By refining the granularity of software architecture management based on functions and their safety levels, it enables strict isolation of each software module, meeting functional safety isolation requirements and preventing crosstalk between independent functional faults.

[0079] Figure 2 A schematic diagram of a system architecture constructed according to the method provided in embodiments of the present invention is shown. It is worth noting that... Figure 2 Only a portion of the software modules of the software architecture constructed according to the method provided in the embodiments of the present invention are shown. This software architecture may also include more software modules. For example... Figure 2As shown, the software architecture includes the following software modules: systemapplication-core0, core0-BSW-ASILD, core0-CDD-ASILD, core0-NVM-ASILD, and core0-DIA-ASILD. Implementing the functionality of the core0-BSW-ASILD software module requires the following functions: configuration word, signal routing, CAN / LIN proxy (CAN bus / LIN bus proxy), platform health monitoring, public CAN low-latency TX and RX proxy, remote calibration, A-core calibration, OS boot, common CAN protocol stack, high-frequency message protocol stack, and resource monitoring. Therefore, the configuration word, signal routing, CAN / LIN proxy (CAN bus / LIN bus proxy), platform health monitoring, public CAN low-latency TX and RX proxy, remote calibration, A-core calibration, OS boot, common CAN protocol stack, high-frequency message protocol stack, and resource monitoring are grouped into the same software module. In prior art, configuration words, signal routing, CAN / LIN proxy (CAN bus / LIN bus proxy), platform health monitoring, public CAN low-latency TX and RX proxy, remote calibration, and A-core calibration belong to different software modules at the application layer, while OS boot, public CAN protocol stack, high-frequency message protocol stack, and resource monitoring belong to different software modules at the underlying layer. However, in this embodiment of the invention, the same function may involve functions at the application layer, adaptation layer, and underlying layer.

[0080] In an optional embodiment, the category of function includes the category of communication protocol. Step S103 determines the software modules in the target software system based on the category of function and / or security level, including: deploying the protocol stacks corresponding to different categories of communication protocols into different software modules.

[0081] For example, the communication protocols include: Private Controller Area Network (PCN) Bus Protocol (Private CAN Protocol), Public Controller Area Network (PCN) Bus Protocol (Public CAN Protocol), and Ethernet Protocol (ETHNET Protocol). In this embodiment, the protocol stacks corresponding to the Private Controller Area Network (PCN) Bus Protocol, Public Controller Area Network (PCN) Bus Protocol, and Ethernet Protocol are deployed in different software modules. That is, the CAN protocol stack and the ETHNET protocol stack are deployed in separate applications, and the Private CAN and Public CAN protocol stacks are deployed in separate applications.

[0082] In an optional embodiment, if there are functions that require the use of a proprietary Controller Area Network (CAN) bus protocol, the proprietary CAN bus protocol and the functions are deployed in the same software module. That is, the proprietary CAN protocol and the corresponding services are deployed in one application.

[0083] In an optional embodiment, if the software architecture constructed according to the construction method provided in this embodiment is deployed on a multi-core controller, the software modules can be deployed on different cores according to the functional size and load requirements of the software modules, following the principle of load balancing. Different types of cores support different security levels; for example, the highest security level supported by a lockstep core is ASILD, while the highest security level supported by a single core is ASILB.

[0084] Figure 3 A flowchart illustrating a method for constructing a software architecture according to another embodiment of the present invention is shown. Figure 3 As shown, the method includes:

[0085] Step S301: Determine the design requirements of the target software system. The design requirements shall include at least functional requirements and functional safety requirements.

[0086] Step S302: Analyze and classify the functional requirements and functional safety requirements to determine the category and safety level of the function.

[0087] Step S303: Determine the software modules in the target software system based on the category of function and / or security level.

[0088] Step S304: Map the relevant data of each software module to a fixed physical address space in memory; wherein, the relevant data includes one or more of the following: the code of the software module, private variables, shared variables, and scalar values.

[0089] Steps S301-S303 can be referred to Figure 1 The embodiments shown are not described in detail here to avoid redundancy.

[0090] In step S304, one or more of the following elements from each software module—code, private variables, shared variables, and scaling values—are mapped to fixed physical address spaces in memory. For example, the code of software module A is mapped to fixed address space 1 in memory; the private variables of software module A are mapped to fixed address space 2 in memory; the shared variables of software module A are mapped to fixed address space 3 in memory; the scaling values ​​of software module A are mapped to fixed address space 4 in memory; the code of software module B is mapped to fixed address space 5 in memory; the private variables of software module B are mapped to fixed address space 6 in memory; the shared variables of software module B are mapped to fixed address space 7 in memory; and the scaling values ​​of software module B are mapped to fixed address space 8 in memory. This allows the faulty software module to be located based on its location when a fault is detected.

[0091] In optional embodiments, when mapping the code, private variables, shared variables, and scalar values ​​of each software module, the embodiments of the present invention also need to meet the following requirements:

[0092] The code of all software modules is located at contiguous physical addresses in memory;

[0093] Shared variables across all software modules are physically located in contiguous memory addresses.

[0094] The calibrated values ​​of all software modules are located in contiguous physical memory addresses.

[0095] The physical addresses of the private variables of all software modules in memory are not contiguous.

[0096] Alternatively, the following requirements must be met:

[0097] The code of all software modules is located at contiguous physical addresses in memory;

[0098] Shared variables across all software modules are physically located in contiguous memory addresses.

[0099] The calibrated values ​​of all software modules are located in contiguous physical memory addresses.

[0100] All private variables of all software modules have contiguous physical addresses in memory.

[0101] That is, in this embodiment, the physical addresses of the code of all software modules are continuous, the physical addresses of shared variables are continuous, and the physical addresses of calibrated variables are continuous, while the physical addresses of the private variables of all software modules may be discontinuous.

[0102] In an optional embodiment, the method for constructing the software architecture further includes: setting permissions for each software module; wherein setting permissions for each software module includes one or more of the following:

[0103] Configure each software module to have permission to execute the code of all software modules (i.e., each software module can read and execute the code of all software modules);

[0104] Each software module is configured to have read and write permissions for its own private and shared variables (i.e., each software module can read and write its own private and shared variables).

[0105] Configure each software module to have read-only access to shared variables of other software modules (i.e., each software module can only read shared variables of other software modules);

[0106] Configure each software module to have read-only permissions for all calibration values ​​(i.e., all software modules can read all calibration values, and all calibration values ​​can only be written by the calibration function).

[0107] In an optional embodiment, the method for constructing the software architecture further includes: setting up a global shared area in memory, and granting software modules with specified functions read and write permissions to the global shared area.

[0108] In an optional embodiment, the method for constructing this software architecture further includes: fault management on a module-by-module basis. For example, when unauthorized access occurs, the faulty software module (hereinafter referred to as the faulty software module) is restarted. During restart, tasks of this software module are no longer scheduled, and specified information is provided to the software modules receiving the output of the faulty software module. Time monitoring of the tasks of this software module is also stopped. Simultaneously, after the restart is complete, the tasks of this software module are rerun to ensure that the fault of this software module does not cause other software modules to malfunction.

[0109] The software architecture construction method provided in this invention analyzes and classifies the functional requirements and functional safety requirements of the target software system to determine the category and safety level of functions. Using the category and / or functional safety level as the granularity, the method identifies the software modules within the target software system. This method divides software modules according to functional requirements, thereby constructing a new software architecture. It refines the granularity of software architecture management based on functions and their safety levels, enabling strict isolation of each software module. This meets functional safety isolation requirements, avoids crosstalk between independent functional faults, and ensures low latency and high reliability in communication between different functional safety partitions.

[0110] Figure 4 A schematic diagram of the structure of a software architecture construction apparatus according to an embodiment of the present invention is shown. Figure 4 As shown, the software architecture construction apparatus 400 includes:

[0111] The determination module 401 is used to determine the design requirements of the target software system, wherein the design requirements include at least functional requirements information and functional safety requirements;

[0112] Analysis module 402 is used to parse and classify the functional requirement information and the functional safety requirements to determine the category and security level of the function;

[0113] The segmentation module 403 is used to determine the software modules in the target software system based on the category and / or security level of the function.

[0114] Optionally, the partitioning module is further configured to: deploy functions of the same security level and the same category into the same software module, deploy functions of different security levels and the same category into different software modules, and deploy functions of the same security level and different categories into different software modules.

[0115] Optionally, the categories of the functions include: application layer class, underlying class, and adaptation layer class; each of the application layer class, the underlying class, and the adaptation layer class includes multiple subclasses;

[0116] The partitioning module is further configured to: determine the software modules in the target software system based on the functions and / or security levels corresponding to the multiple subclasses included in the application layer class, the underlying class, and the adaptation layer class, using the partitioning granularity.

[0117] Optionally, the categories of the functions include the categories of communication protocols; the partitioning module is also used to: deploy the protocol stacks corresponding to different categories of communication protocols into different software modules.

[0118] Optionally, the communication protocol categories include: private controller area network bus protocol, public controller area network bus protocol, and Ethernet protocol;

[0119] The partitioning module is also used to deploy the protocol stacks corresponding to the private controller LAN bus protocol, the public controller LAN bus protocol, and the Ethernet protocol to different software modules.

[0120] Optionally, the partitioning module is further configured to: if there is a function that requires the use of the private controller local area network bus protocol, then deploy the private controller local area network bus protocol and the function into the same software module.

[0121] Optionally, the apparatus further includes a mapping module for: mapping relevant data of each software module to a fixed physical address space in memory; wherein the relevant data includes one or more of the software module's code, private variables, shared variables, and scalar values.

[0122] Optionally, the mapping module is further configured to: have all the code of the software modules in contiguous physical addresses in memory; have all the shared variables of the software modules in contiguous physical addresses in memory; have all the scalar values ​​of the software modules in contiguous physical addresses in memory; and have all the private variables of the software modules in non-contiguous physical addresses in memory.

[0123] Optionally, the mapping module is further configured to: ensure that the physical addresses of the code of all the software modules are contiguous in memory; ensure that the physical addresses of the shared variables of all the software modules are contiguous in memory; ensure that the physical addresses of the scalar values ​​of all the software modules are contiguous in memory; and ensure that the physical addresses of the private variables of all the software modules are contiguous in memory.

[0124] Optionally, the device further includes a permission setting module, used to: set the permissions of each software module; wherein setting the permissions of each software module includes one or more of the following: setting each software module to have the permission to execute the code of all software modules; setting each software module to have the permission to read and write its own corresponding private variables and shared variables; setting each software module to have the permission to read only the shared variables corresponding to other software modules; setting each software module to have the permission to read only all calibrated variables.

[0125] Optionally, the permission setting module is further configured to: set a global shared area in memory, and configure software modules with specified functions to have the permission to read and write the global shared area.

[0126] Optionally, the device further includes a fault detection module, configured to: restart the faulty software module in response to detecting a faulty software module, and provide specified information to the software module receiving the output of the faulty software module.

[0127] The above-described apparatus can execute the methods provided in the embodiments of the present invention, and has the corresponding functional modules and beneficial effects for executing the methods. Technical details not described in detail in this embodiment can be found in the software architecture construction method provided in the embodiments of the present invention.

[0128] Figure 5 A schematic diagram of the structure of an electronic device according to an embodiment of the present invention is shown. Figure 5 As shown, the electronic device includes:

[0129] The system includes a processor 501, a communication interface 502, a memory 503, and a communication bus 504. The processor 501, communication interface 502, and memory 503 communicate with each other via the communication bus 504.

[0130] Memory 503 is used to store computer programs;

[0131] When processor 501 executes the program stored in memory 503, it performs the following steps:

[0132] Determine the design requirements of the target software system, which include at least functional requirements and functional safety requirements;

[0133] The functional requirements information and functional safety requirements are analyzed and classified to determine the category and security level of the function.

[0134] The software modules in the target software system are determined by using the category and / or security level of the function as the granularity.

[0135] The communication bus mentioned in the above terminal can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0136] The communication interface is used for communication between the aforementioned terminal and other devices.

[0137] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0138] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0139] In another embodiment of the present invention, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform the construction method of any of the software architectures described in the above embodiments.

[0140] In another embodiment of the present invention, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the construction method of the software architecture described in any of the above embodiments.

[0141] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0142] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0143] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0144] The above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A method for constructing a software architecture, characterized in that, The method for architectural design of a target software system includes: Determine the design requirements of the target software system, which include at least functional requirements and functional safety requirements; The functional requirements information and functional safety requirements are analyzed and classified to determine the category and security level of the function. The software modules in the target software system are determined by using the category and / or security level of the function as the granularity.

2. The method according to claim 1, characterized in that, The step of determining the software modules in the target software system based on the category and / or security level of the function includes: Deploying functions with the same security level and category into the same software module, deploying functions with different security levels but the same category into different software modules, and deploying functions with the same security level but different categories into different software modules.

3. The method according to claim 1, characterized in that, The functional categories include: application layer class, underlying layer class, and adaptation layer class; each of the application layer class, the underlying layer class, and the adaptation layer class includes multiple subclasses; The step of determining the software modules in the target software system based on the category and / or security level of the function includes: The software modules in the target software system are determined by using the functions and / or security levels corresponding to the multiple subclasses included in the application layer class, the underlying class, and the adaptation layer class as the granularity of division.

4. The method according to any one of claims 1-3, characterized in that, The categories of the functions include the categories of communication protocols; the process of determining the software modules in the target software system based on the categories of the functions and / or security levels includes: Deploy the protocol stacks corresponding to different types of communication protocols into different software modules.

5. The method according to claim 4, characterized in that, The communication protocols include: private controller area network bus protocol, public controller area network bus protocol, and Ethernet protocol; The deployment of protocol stacks corresponding to different types of communication protocols into different software modules includes: The protocol stacks corresponding to the private controller LAN bus protocol, the public controller LAN bus protocol, and the Ethernet protocol are deployed in different software modules.

6. The method according to claim 5, characterized in that, The deployment of protocol stacks corresponding to different types of communication protocols into different software modules includes: If there are functions that require the use of the Private Controller Area Network (PCN) Bus Protocol, then deploy the PCN Bus Protocol and the functions into the same software module.

7. The method according to claim 1, characterized in that, The method further includes: The relevant data of each software module is mapped to a fixed physical address space in memory; wherein, the relevant data includes one or more of the following: the software module's code, private variables, shared variables, and scalar values.

8. The method according to claim 7, characterized in that, The process of mapping the relevant data of each software module to a fixed physical address space in memory includes one or more of the following: The code of all the software modules is physically located in contiguous blocks of memory; The shared variables of all the software modules are physically located in contiguous memory. The calibrated values ​​of all the software modules are located in contiguous physical addresses in memory; The private variables of all the software modules described are not located at contiguous physical addresses in memory.

9. The method according to claim 7, characterized in that, The process of mapping the relevant data of each software module to a fixed physical address space in memory includes one or more of the following: The code of all the software modules is physically located in contiguous blocks of memory; The shared variables of all the software modules are physically located in contiguous memory. The calibrated values ​​of all the software modules are located in contiguous physical addresses in memory; All the private variables of the software modules described are located at contiguous physical addresses in memory.

10. The method according to claim 7, characterized in that, The method includes: setting permissions for each software module; wherein setting permissions for each software module includes one or more of the following: Configure each software module to have permission to execute the code of all software modules; Each software module is configured to have read and write permissions for its own private and shared variables; Configure each software module to have read-only access to shared variables of other software modules; Configure each software module to have read-only permissions for all calibration values.

11. The method according to claim 10, characterized in that, The method further includes: Set up a global shared area in memory, and grant read and write permissions to specific software modules that have specific functions.

12. The method according to any one of claims 7-11, characterized in that, The method further includes: in response to detecting a faulty software module, restarting the faulty software module, and providing specified information to the software module receiving the output of the faulty software module.

13. A software architecture construction apparatus, characterized in that, The apparatus for architectural design of a target software system includes: A determination module is used to determine the design requirements of the target software system, wherein the design requirements include at least functional requirements information and functional safety requirements; The analysis module is used to parse and classify the functional requirement information and the functional safety requirements to determine the category and security level of the function; The segmentation module is used to determine the software modules in the target software system based on the category and / or security level of the function.

14. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method as described in any one of claims 1-12.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-12.

Images