WO2020162316A1

WO2020162316A1 - System and method for heterogeneous asymmetric systems which manage mixed critical functionality

Info

Publication number: WO2020162316A1
Application number: PCT/JP2020/003411
Authority: WO
Inventors: キランパンチャンガム; 祐石郷岡; 一芹沢
Original assignee: 日立オートモティブシステムズ株式会社
Priority date: 2019-02-04
Filing date: 2020-01-30
Publication date: 2020-08-13
Also published as: JPWO2020162316A1; JP7096376B2

Abstract

The present disclosure discloses a method and embedded electronic control unit (ECU) system for heterogeneous asymmetric systems, which manage mixed critical functionality. The embedded ECU system comprises: a split module which splits a plurality of processors into a first set of processors and a second set of processors; and an extraction module which extracts a safety setting value for the first set of processors. The safety setting value is generated during the split. The safety setting value of the first set of processors is verified on the basis of a trusted safety setting value, and the first set of processors access system resources on the basis of the result of the verification.

Description

System and method for managing mixed critical functionality for heterogeneous asymmetric systems

The present invention relates generally to embedded systems, and more specifically, but not exclusively, to systems and methods for managing mixed critical functionality for heterogeneous asymmetric systems.

In recent years, the use of electronic components in automotive systems has increased tremendously, resulting in the replacement of purely mechanical implementations of various functions. In general, a deeply embedded electronic control unit (ECU) cannot support a complicated operation, and a new ECU may be required to execute the complicated operation. However, the introduction of new ECUs for complex calculations increases maintenance and manufacturing costs. Today, various ECU functions can be integrated into a single ECU hardware. However, while the combined single ECUs are being executed in combination, some functions of different importance may interfere with each other, leading to a fatal system failure and memory corruption. Therefore, functional safety issues are becoming more important in the design and development of embedded systems.

Existing embedded systems provide a way to control execution privileges, and thus provide isolation of mixed importance functions on the same hardware. In particular, privileges are local to the processor in which the task is executing. In general, the operating system can assign and manage privileges for any function. However, the operating system is vulnerable to modification by the user and thus may eventually execute a malicious program, causing an interruption between the systems. In addition, localized privileges are not visible to other processors in dissimilar hardware, leading to a security violation. In addition, locally stored important data may be bypassed by the processor and accessed via direct memory access (Direct Memory Access, DMA).

The information disclosed in this Background section of the present disclosure is only for improving the understanding of the general background of the present invention, and the information is not limited to the prior art already known to those skilled in the art. It should not be considered as an admission or any form of suggestion of forming.

In one embodiment, the present disclosure may relate to an embedded electronic control unit (ECU) system for managing mixed critical functionality for heterogeneous asymmetric systems. The embedded ECU system may include a plurality of processors and a memory communicatively coupled to the processor, wherein the memory, when executed, causes the embedded ECU system to include the plurality of processors in a first processor set and a second set. A processor-executable instruction that may cause the security setting of the first processor set to be extracted. Security settings are generated during the split. Further, the security settings of the first set of processors are verified based on the trusted security settings. Then, the first set of processors access system resources based on the results of the verification.

In one embodiment, the present disclosure may relate to a method for managing mixed critical functionality for heterogeneous asymmetric systems. The method includes dividing the plurality of processors into a first set of processors and a second set of processors and extracting a safety setting for the first set of processors. The security settings are generated during the split and the security settings for the first set of processors are verified based on the trusted security settings. Then, the first set of processors access system resources based on the results of the verification.

The above outline is merely exemplary and is not intended to be limiting in any way. In addition to the exemplary aspects, embodiments and features described above, further aspects, embodiments and features will become apparent by reference to the drawings and the following detailed description.

The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate example embodiments and, together with a brief description of the drawings, serve to explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of systems and/or methods consistent with embodiments of the present invention will now be described, by way of example only, with reference to the accompanying figures.
FIG. 6 illustrates an exemplary block diagram of an embedded electronic control unit system according to some embodiments of the present disclosure. FIG. 6 illustrates an exemplary block diagram of an embedded electronic control unit system according to some embodiments of the present disclosure. 6 illustrates an internal architecture of an embedded ECU system configured to manage mixed critical functionality for heterogeneous asymmetric systems, according to some embodiments of the present disclosure. 6 illustrates an exemplary representation of mixed critical functionality management for heterogeneous asymmetric systems, according to some embodiments of the present disclosure. 6 illustrates an exemplary representation of mixed critical functionality management for heterogeneous asymmetric systems, according to some embodiments of the present disclosure. 6 illustrates an exemplary representation of mixed critical functionality management for heterogeneous asymmetric systems, according to some embodiments of the present disclosure. 6 illustrates an exemplary representation of mixed critical functionality management for heterogeneous asymmetric systems, according to some embodiments of the present disclosure. 6 illustrates an exemplary representation of mixed critical functionality management for heterogeneous asymmetric systems, according to some embodiments of the present disclosure. 6 illustrates an exemplary representation of performing security settings, according to some embodiments of the present disclosure. 6 illustrates an exemplary representation of performing security settings, according to some embodiments of the present disclosure. 6 illustrates an exemplary representation of performing security settings, according to some embodiments of the present disclosure. 6 illustrates a flowchart illustrating a method of managing mixed critical functionality for heterogeneous asymmetric systems, according to some embodiments of the present disclosure. FIG. 6 shows a block diagram of an exemplary computer system 600 for implementing embodiments consistent with this disclosure.

Those skilled in the art should understand that any block diagrams in the present specification represent conceptual diagrams of exemplary systems embodying the principles of the present invention. Similarly, any flowchart, flow diagram, state diagram, pseudo code, etc., may be substantially represented by a computer-readable medium, whether or not explicitly indicated by such a computer or processor. It will be appreciated that it represents various processes that may be performed regardless of.

In this document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the invention described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

While the disclosure is open to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will be described in detail below. However, this disclosure is not intended to be limited to the particular forms disclosed, and conversely, this disclosure extends to all modifications, equivalents, and alternatives falling within the scope of this disclosure. It should be understood.

The terms “comprises”, “comprising”, or any other variation thereof refer to a configuration, device or method including a recitation of components or steps It is not exclusive to the components or steps only, as it is not explicitly recited or may include other components or steps specific to such configurations or devices or methods. It is intended to extend to inclusion. In other words, the presence of one or more elements in a system or apparatus that are advanced by “comprises... a” by other elements or additional elements in the system or method. Is not excluded without further restrictions.

The following detailed description of embodiments of the present disclosure refers to the accompanying drawings, which form a part of this specification. Specific embodiments are shown by way of illustration in the accompanying drawings, in which the disclosure can be practiced. These embodiments have been described in sufficient detail to enable those skilled in the art to practice the present disclosure, other embodiments may be utilized, and changes may be made without departing from the scope of the present disclosure. It should be understood that it is good. Therefore, the following description should not be considered in a limiting sense.

Embodiments of the present disclosure relate to embedded electronic control unit (ECU) systems for managing mixed and critical functions for heterogeneous asymmetric systems. In one embodiment, a heterogeneous asymmetric system may refer to a system with two or more processors that differ in architecture or microarchitecture. In one embodiment, the embedded ECU system controls one or more electrical systems or subsystems. In the present disclosure, an embedded ECU system comprises multiple processors, each processor executing an instance of a safety module. The plurality of processors is divided into a first set of processors and a second set of processors. In one embodiment, each processor of the first set of processors is a low reliability processor and each processor of the second set of processors is a high reliability processor. During every request to access system resources, the embedded ECU system extracts the safety setpoint for the first set of processors. The extracted security settings for the first set of processors are hashed and sent to the second set of processors for verification against trusted security settings. The embedded ECU system thereby provides the first set of processors with access to system resources based on the verification. The present disclosure enhances reliability by suppressing interference with the safe operation of trusted components of the system due to the effects of non-compliant components.

1a and 1b show an exemplary block diagram of an embedded electronic control unit system, according to some embodiments of the present disclosure.

As shown in FIG. 1a, the environment includes an embedded electronic control unit (ECU) system 101. The embedded ECU system 101 stores input/output (I/O) interfaces 103, a plurality of processors 107 (“CPU” or “processor”, referred to as processor 107), and instructions executable by the processor 107. Memory 105. The I/O interface 103 is coupled to the processor 107. Input signals and/or output signals are communicated via this coupling. Those skilled in the art will understand that FIG. 1a is an exemplary embodiment and the embedded ECU system 101 may include any other unit not explicitly mentioned in this disclosure. The embedded ECU system 101 may be used to manage mixed critical functionality for heterogeneous asymmetric systems. In one embodiment, the embedded ECU system 101 runs the instance of the safety module at the highest privilege level. In one embodiment, the privilege level may be a level of authority for access and execution within the embedded ECU system 101. The embedded ECU system 101 partitions the processor 107 as shown in FIG. 1b. Processor 107 may be divided into a _first set of processors 107 ₁ and a second set of processors 107 ₂ . In one embodiment, a first set of processor 1071 may be a low-reliability processors, a set 107 of the _second processor may be a reliable processor. In particular, the low-reliability processor is a safety non-compliant processor and the high-reliability processor is a safety conforming processor. In one embodiment, a safety-compliant processor may refer to a processor that may be rated higher than a non-safety-compliant processor based on standard safety integrity levels. As shown in FIG. 1b, the first set of processors 107 ₁ comprises a processor 107 ₁₁ , a processor 107 ₁₂ ,..., And a processor 107 _1n (collectively the first set of processors 107 ₁ ). Including. Similarly, the second set of processors 107 ₂ includes a processor 107 ₂₁ , a processor 107 ₂₂ ,... And a processor 107 _2n (collectively referred to as a second set of processors 107 ₂ ). Each of the _first set of processors 107 ₁ includes a respective security module 115 ₁ . Similarly, each of the _second set of processors 107 ₂ includes a respective security module 115 ₂ .

At any moment, upon receiving a request to access system resources 113, embedded ECU system 101 may extract a safety setpoint from safety module 115 ₁ of _first processor set 107 ₁ . In one embodiment, the security settings are generated during the partitioning of processor 107. In one embodiment, the first set of processors 107 ₁ receives security settings from the _second set of processors 107 ₂ based on the partitioning and the security of each memory management unit (MMU). Set the sex setting value. Furthermore, the extracted security setting value of the first processor set 107 ₁ is hashed and transmitted to the _second processor set 107 ₂ by an inter-processor communication (IPC) technique. A person of ordinary skill in the art will understand that the scope of the present disclosure may include any other technique for transmitting the safety setting, which is not explicitly mentioned herein. Further, the security settings of the _first set of processors 107 ₁ are verified based on the trusted security settings of the _second set of processors 107 ₂ . In one embodiment, the security settings include ranges that allow access to the first set of processors 1071 and the trusted security settings include ranges that allow access categorized by multiple levels. Including. In one embodiment, the range may be configurable based on the type of application. For example, the range may be “0x000203 to 0x020304”. In one embodiment, the verification of the safety settings of the _first set of processors 107 ₁ is performed by an external verification module (not explicitly shown in FIG. 1b) associated with the embedded ECU system 101. Good. In one embodiment, the safety settings for the _first set of processors 107 ₁ may be performed by a verification module (not explicitly shown) that is external to the embedded ECU system 101. In another embodiment, the embedded ECU system 101 may verify the safety settings for the first processor set 1071. The security settings of the first processor set 107 ₁ are verified by comparing the security settings to the trusted security settings of the second processor set 107 ₂ . The embedded ECU system 101 may then provide access to the system resources 113 to the first set of processors 107 ₁ based on the results of the verification. The access may be associated with, for example, a requested memory location in memory 105, a writable and non-rewritable status on the memory location, and the like. In one embodiment, the embedded ECU system 101 is associated with an access unit (not explicitly shown in the figure) for providing access to the _first set of processors 107 ₁ based on the results of the verification. May be.

FIG. 2 illustrates the internal architecture of an embedded ECU system configured to manage mixed critical functionality for heterogeneous asymmetric systems, according to some embodiments of the present disclosure.

As shown in FIG. 2, the embedded ECU system 101 may include data 200, and one or more modules 209 described in detail herein. In one embodiment, the data 200 may be stored in the memory 105. The data 200 may include, for example, divided data 201, safety setting data 203, verification data 205, and other data 207.

The partition data 201 may include details regarding the partitioning of the processor 107 into a _first set of processors 107 ₁ and a second set of processors 107 ₂ . The details may include security settings associated with the processor 107.

The safety setting data 203 may include safety setting values extracted from the first processor set 107 ₁ . In one embodiment, the safety settings may be generated during the split.

The validation data 205 may include results of comparing the security settings of the first processor set 107 ₁ with the trusted security settings of the second processor set 107 ₂ . In one embodiment, the verification results may include access level details to the system resources 113 of the _first set of processors 107 ₁ .

Other data 207 may store data, including temporary data and temporary files, generated by one or more modules 209 to perform various functions of embedded ECU system 101.

In one embodiment, the data 200 in the memory 105 is processed by one or more modules 211 residing in the memory 105 of the embedded ECU system 101. In one embodiment, one or more modules 209 may be implemented as a dedicated unit. The term module as used herein refers to an application specific integrated circuit (ASIC), electronic circuit, field programmable gate array (field-programmable gate array, FPGA), programmable system-on-chip (ProgrammableSmall). -On-Chip, PSoC), combinatorial logic, and/or other suitable components that provide the described functionality. In some implementations, one or more modules 209 may be communicatively coupled to the processor 107 to perform one or more functions of the embedded ECU system 101. One or more modules 209 are new hardware when configured with the functionality defined in this disclosure.

In one implementation, the one or more modules 209 may include, but are not limited to, the split module 211, the extraction module 213, and the transmission module 215. One or more modules 209 may also include other modules 217 for performing miscellaneous functions of embedded ECU system 101. In one embodiment, the other modules 217 may include verification modules and access modules.

The partition module 211 may virtually partition the processor 107 into a first set of processors 107 ₁ and a second set of processors 107 ₂ . In one embodiment, the partitioning module 211 may partition the processor 107 based on the safety compliance of each processor of the processor 107. For example, each non-safety conforming processor of processor 107 is divided into a _first set of processors 107 ₁ and each safety conforming processor of processor 107 is divided into a _second set of processors 107 ₂ . In one embodiment, each processor of the _first set of processors 107 ₁ is a low reliability processor and each processor of the _second set of processors 107 ₂ is a high reliability processor.

Upon receiving any request from the _first set of processors 107 ₁ to access system resources 113, the extraction module 213 may extract the safety settings for the _first set of processors 107 ₁ . Further, the extracted security settings of the _first set of processors 107 ₁ may be hashed and indexed.

The sending module 215 may send the hashed security settings of the _first set of processors 107 ₁ to the second set of processors 107 ₂ by IPC technology.

The safety setpoints for the _first set of processors 107 ₁ are stored in the second set of processors 107 ₂ by an external verification module associated with the embedded ECU system 101 or by a verification module external to the embedded ECU system 101. It is verified by comparing it with a trusted safety setting. Based on the results of the verification, the first set of processors 1071 may access system resources 113.

3a-3e show example representations of managing mixed critical functionality for heterogeneous asymmetric systems, according to some embodiments of the present disclosure.

Referring now to FIG. 3a, an exemplary representation 300 of managing mixed critical functionality for a heterogeneous asymmetric system is shown. In FIG. 3 a, the exemplary representation 300 includes an embedded ECU system 101. The embedded ECU system 101 includes a processor 301 that is a low reliability processor and a processor 302 that is a high reliability processor. Those skilled in the art will appreciate that FIG. 3a is an exemplary embodiment, and the present disclosure may include more than one processor for both low and high reliability processors. .. The processor 301 and the processor 302 are virtually divided as indicated by the dotted line in FIG. 3a. Furthermore, the first partition, the first processor 301, includes a safety module 303, a partitioning module 305, an extraction module 307 that is separate from the operating system 308 of the embedded ECU system 101, as well as a non-updatable first. Application 309 and a second application 311 in an updatable format. In one embodiment, the second application 311 in processor 301 may be updated. Processor 302 is associated with application 312, which must not be in an updatable format. The first processor 301 receives and sets the safety setting value in the corresponding memory management unit (MMU). The set security setting value of the processor 301 is extracted by the extraction module 307, hashed, and transmitted to the processor 302 by IPC technology. The processor 302 includes a verification module 315 that validates the security settings of the processor 301 with the trusted security settings of the processor 302. Therefore, during any update of the second application 311, no access is granted by any DMA attack. Similarly, FIG. 3b illustrates an example of mixed critical function management for a heterogeneous asymmetric system having a processor 301 as an unreliable processor and a highly reliable SoftIp 317 on a field programmable gate array (FPGA). Shows a typical expression. In one embodiment, some implementations may include the FPGA as a trusted processor/SoftIp subsystem. The verification of the safety setting value of the processor 301 may be executed by the safety verification engine 316 which is a dedicated SoftIp. Thus, when receiving any updates for the second application, the security settings of processor 301 are verified, and access during such updates is not permitted by any DMA attack.

FIG. 3c illustrates a heterogeneous subsystem of three entities for managing mixed critical functionality having a processor 301 as a low reliability processor, a processor 302 as a high reliability processor, and a SoftIp 317 on the FPGA. An exemplary representation is shown. Both processor 301 and processor 302 may send their respective safety settings in SoftIp 317 on the FPGA. Verification of safety settings may be implemented by SoftIp 317 on the FPGA. In one embodiment, the FPGA may expose a secure memory region and a non-secure memory region implemented as part of the safety verification engine 316. Therefore, if it receives any updated for the second application 311 _1, the safety set value of the processor 301 is verified, the access of such updating is in any DMA attacks, it will not be allowed ..

Similarly, FIG. 3d shows a 3 for managing important mixed functions having on the FPGA a processor 301 as a low reliability processor, a processor 302 as a high reliability FPGA, and an intermediate processor with SoftIp 317. 3 illustrates an exemplary representation of a heterogeneous subsystem of one entity. Both processor 301 and processor 302 may send the safety settings in SoftIp on the FPGA. In one embodiment, intermediate processors with SoftIp 317 may assign different levels of safety split restrictions. The FPGA may expose safe and non-safe memory areas implemented as part of the security verification engine 316. Therefore, if it receives any updated for the second application 311 _1, the safety set value of the processor 301, is verified by safety validation engine 316, access of such updating is in any DMA attack , Never allowed. FIG. 3e shows an exemplary implementation for managing mixed critical functionality with processor 301 as a low reliability processor and processor 302 as a high reliability processor with safety middleware 318. In one embodiment, security middleware 318 may be used to detect security violations between applications. Security middleware 318 may be deployed to filter security violations and anomalies at the application level. In one embodiment, the security middleware 318 may be a component of the kernel.

4a, 4b, and 4c show example representations of performing security settings, according to some embodiments of the present disclosure.

4a and 4b show an exemplary representation of a report of an access violation to a safety setting in the embedded ECU system 101. FIG. 4c shows an exemplary representation of a report of access authorization to safety settings in the embedded ECU system 101. In one embodiment, preset values for memory address, access type, safety unit ID, and safety level may be extracted based on memory or device requirements from the _first set of processors 107 ₁ ( Referred to as the security setting of the _first set of processors 107 ₁ . Consider the first scenario shown in Figure 4a. In this case, a request by the application associated with the _first set of processors 107 ₁ to access a memory location of access type “Write(W)” with safety unit ID “0x30” and memory address “0x80001020”. Is received. Upon receiving the request, the corresponding MMU settings are set. The MMU settings are represented by the exemplary table 401 shown in Figure 4a. The embedded ECU system 101 may compare the safety settings associated with the request with the configured MMU settings. As shown in the table 401, the memory address “0x80001020” corresponding to the request is within the memory address range of “0x80001000-0x8000012FF”. In addition, as shown in Table 402, the safety unit ID “0x30” of the safety level “2” is preset during the initialization. The memory address range “0x80001000-0x800012FF” provides access to the application with safety unit ID “0x30” only by type “read”. Therefore, by comparison, the embedded ECU system 101 may report an access request from the _first processor set 107 ₁ as being in violation. This is because the request is for the "write" access type which is not permitted for the memory address range of "0x80001000-0x8000012FF". Consider the second scenario shown in Figure 4b. In this case, a request by the application associated with the _first set of processors 107 ₁ to access a memory location of access type “Read(R)” with safety unit ID “0x34” and memory address “0x80001020”. Is received. Upon receiving the request, the corresponding MMU settings are set. The embedded ECU system 101 may compare the safety settings associated with the request with the configured MMU settings. As shown in the table 401, the memory address “0x80001020” corresponding to the request is within the memory address range of “0x80001000-0x8000012FF”. However, the memory address range "0x80001000-0x800012FF" provides "read" type access to the application with safety unit ID "0x30". Therefore, by comparison, the embedded ECU system 101 may report an access request from the _first processor set 107 ₁ as a violation. This is because the safety unit ID “0x34” is not permitted for the memory address range “0x80001000-0x8000012FF”. In one embodiment, access violation, while issuing an emergency software reset to a set 107 of the _first processor, is reported via the software interrupt to set 107 of the _first processor, OEM You may perform the recovery operation etc. which were set. As shown in the table 401, the violation operation is mapped to the corresponding operation ID. The permitted safety unit ID is a function of a plurality of safety unit IDs (Safety Unit IDs, SUIs) set so as to be associated with a specific address range. During system initialization, the security level is used to distinguish units of heterogeneous systems of multiple entities, and the SUI represents a unique ID assigned to a particular processing entity within the system.

Similarly, as shown in FIG. 4c, the request is made by the application associated with the _first processor set 107 ₁ with safety unit ID “0x30”, memory address “0x80001020”, and access type “Read(R)”. , For access to memory locations. Upon receiving the request, the corresponding MMU settings are set. The embedded ECU system 101 may compare the safety settings associated with the request with the configured MMU settings. As shown in the table 401, the memory address “0x80001020” corresponding to the request is within the memory address range of “0x80001000-0x8000012FF”. In addition, the memory address range “0x80001000-0x800012FF” provides access to only the “read” type to applications with safety unit ID “0x30”. Therefore, by comparison, the embedded ECU system 101 may report an access request from the _first set of processors 107 ₁ as approved. This is because the request is for the “R” access type that is permitted for the memory address range of “0x80001000-0x8000012FF”.

FIG. 5 shows a flow chart illustrating a method of managing mixed critical functionality for heterogeneous asymmetric systems, according to some embodiments of the present disclosure.

As shown in FIG. 5, method 500 includes one or more blocks for managing mixed critical functionality for heterogeneous asymmetric systems. Method 500 may be described in the general context of computer-executable instructions. Generally, computer-executable instructions may include routines, programs, objects, components, data structures, procedures, modules, and functions that perform particular functions or implement particular abstract data types.

The order in which method 500 is described is not intended to be construed as limiting, and any number of the method blocks described may be combined in any order to implement the method. In addition, individual blocks may be deleted from the method without departing from the scope of the invention described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.

At block 501, the plurality of processors 107 is divided by the division module 211 into a first set of processors 107 ₁ and a second set of processors 107 ₂ .

At block 503, the safety settings for the _first set of processors 107 ₁ are extracted by the extraction module 213. Security settings are generated during the split. Set 107 ₁ safety setpoint of the first processor is verified based on the safety settings that are trusted based on the result of the verification, set 107 of the _first processor, the system resources 113 to access. The safety settings of the _first set of processors 107 ₁ are transmitted by the transmission module 215 to the second set of processors 107 ₂ . In one embodiment, an external verification module associated with the embedded ECU system 101 may check the safety settings for the _first set of processors 107 ₁ .

[Computing system]
FIG. 6 shows a block diagram of an exemplary computer system 600 for implementing embodiments consistent with this disclosure. In one embodiment, computer system 600 may be used to implement embedded ECU system 101. Computer system 600 may include a central processing unit (“CPU” or “processor”) 602. Processor 602 may include at least one data processor for managing mixed critical functionality for heterogeneous asymmetric systems. The processor 602 may include a specialized processing device such as an integrated system (bus) controller, a memory management control unit, a floating point unit, a graphics processing unit, a digital signal processing unit, and the like.

Processor 602 may be arranged to communicate with one or more input/output (I/O) devices (not shown) via I/O interface 601. The I/O interface 601 includes, but is not limited to, audio, analog, digital, monoaural, RCA, stereo, IEEE (registered trademark)-1394, serial bus, universal serial bus, USB (registered trademark). )), infrared, PS/2, BNC, coaxial, component, composite, digital visual interface (DVI), high-definition multimedia interface (high-definition multimedia interface, HDMI (registered trademark)), RF antenna , S-picture, VGA, IEEE (registered trademark) 802. n/b/g/n/x, Bluetooth (registered trademark), cellular type (eg, code-division multiple access (code-division multiple access, CDMA), high-speed packet access (high-speed packet access, HSPA+), pan-Europe) A communication protocol/communication method such as a digital mobile communication system (global system for mobile communications, GSM (trademark)), long-term evolution (LTE (trademark), WiMax (trademark), etc.) or the like may be adopted. ..

Using I/O interface 601, computer system 600 may communicate with one or more I/O devices. For example, the input device is an antenna, keyboard, mouse, joystick, (infrared) remote controller, camera, card reader, fax machine, dongle, biometric reader, microphone, touch screen, touch pad, trackball, stylus, scanner, storage device. , Transceivers, video devices/video sources, etc. The output device is a printer, a FAX machine, a video display (for example, a cathode ray tube (CRT), a liquid crystal display (liquid crystal display, LCD), a light-emitting diode (light-emitting diode, LED (trademark)), plasma, plasma. It may be a display panel (Plasma display panel, PDP), an organic light emitting diode display (Organic light-emittering diode display, OLED, etc.), an audio speaker, or the like.

In some embodiments, computer system 600 comprises embedded ECU system 101. Processor 602 may be arranged to communicate with communication network 609 via network interface 603. The network interface 603 may communicate with the communication network 609. The network interface 603 is a direct connection, Ethernet (for example, twisted pair 10/100/1000 Base T), transmission control protocol/Internet protocol (transmission control protocol/internet protocol, TCP/IP), token ring, IEEE (registered trademark) 802. A connection protocol including, but not limited to, .11a/b/g/n/x may be adopted. The communication network 609 is not limited to a direct interconnection, a local area network (local area network, LAN), a wide area network (wide area network, WAN), a wireless network (using a wireless application protocol), the Internet, etc. May be included in the The network interface 603 is a direct connection, Ethernet (for example, twisted pair 10/100/1000BaseT), transmission control protocol/Internet protocol (TCP/IP), token ring, IEEE (registered trademark) 802.11a/b/g/n. Connection protocols may be employed including, but not limited to, /x.

The communication network 609 includes direct interconnection, e-commerce network, peer-to-peer (P2P) network, local area network (LAN), wide area network (WAN), wireless network (for example, using a wireless application protocol). , Internet, Wi-Fi, etc., but are not limited to these. The first network and the second network may be dedicated networks or shared networks, and for communicating with each other, for example, a hypertext transfer protocol (Hypertext Transfer Protocol, HTTP), a transmission control protocol/Internet protocol ( Represents association of various types of networks using various protocols such as TCP/IP) and wireless application protocols (Wireless Application Protocol, WAP). Further, the first network and the second network may include various network devices including routers, bridges, servers, computing devices, storage devices, and the like.

In some embodiments, the processor 602 may be arranged to communicate with a memory 605 (eg, RAM, ROM, etc., not shown in FIG. 6) via a storage interface 604. The storage interface 604 is a serial advanced technology attachment (serial advanced technology attachment, SATA (registered trademark)), integrated drive electronics (Integrated Drive Electronics, IDE), IEEE (registered trademark)-1394, universal serial bus (USB). (Trademark), fiber channel, small computer system interface (Small Computer Systems Interface, SCSI) and other connection protocols are adopted to connect to the memory 605, including but not limited to memory drives, removable disk drives, etc. You may. The memory drive may further include a drum, a magnetic disk drive, a magneto-optical drive, an optical drive, a RAID (Redundant Array of Independent Discs, RAID), a solid state memory device, a solid state drive, and the like.

The memory 605 may store a set of programs or database components including, without limitation, a user interface 606, an operating system 607, and the like. In some embodiments, computer system 600 may store user/application data 606, such as data, variables, records, etc., as described in this disclosure. Such databases may be implemented as fault-tolerant, scalable, secure relational databases, such as Oracle or Sybase.

The operating system 607 can facilitate resource management and operation of the computer system 600. Examples of operating systems include APPLE MACINTOSH (registered trademark) OS X, UNIX (registered trademark), UNIX-like system distributions (for example, BERKELEY SOFTWARE DISTRIBUTION (BSD), FREEBSD (trademark), NETBSD (trademark)). , OPENBSD (trademark), LINUX DISTRIBUTIONS (trademark) (for example, RED HAT (trademark), UBUNTU (trademark), KUBUNUTU (trademark), etc.), IBM (trademark) OS/2, MICROSOFT (trademark) WINDOWS (trademark) (XP (trademark), VISTA (trademark)/7/8, 10, etc.), APPLE (trademark) IOS (trademark), GOOGLE (trademark) ANDROID (trademark), BLACKBERRY (trademark) OS, etc. are not limited. include.

In some embodiments, computer system 600 may implement the stored program components of web browser 608. The web browser 608 is a hypertext browsing application, for example, MICROSOFT (registered trademark) INTERNET EXPLORER (registered trademark), GOOGLE (registered trademark) CHROME (registered trademark), MOZILLA (registered trademark) FIREFOX (registered trademark), and APPLE (registered trademark) SAFARI (registered trademark). Trademark) or the like. For secure web browsing, Secure Hypertext Transfer Protocol (Secure Hypertext Transport Protocol, HTTPS), Secure Socket Layer (Secure Sockets Layer, SSL), Transport Layer Security (Transport Layer Security), etc. can be used to provide TLS. .. The web browser 608 has functions such as AJAX (trademark), DHTML (trademark), ADOBE (trademark) FLASH (trademark), JAVASCRIPT (trademark), JAVA (trademark), an application programming interface (Application Programming Interface, API) and the like. You may use it. In some embodiments, computer system 600 may implement the stored program components of a mail server. The mail server may be an Internet mail server such as Microsoft Exchange or others. Mail servers include ASP™, ACTIVEX™, ANSI™ C++/C#, MICROSOFT™,. Even using functions such as NET™, CGI SCRIPTS™, JAVA™, JAVASCRIPT™, PERL™, PHP™, PYTHON™, WEBOBJECTS™ and others. Good. The mail server is an Internet message access protocol (Internet Message Access Protocol, IMAP), a messaging application programming interface (Messaging Application Programming Interface, MAPI), MICROSOFT (registered trademark) exchange, post office protocol (POP), and simple mail transfer protocol (POP). A communication protocol such as Mail Transfer Protocol, SMTP) or the like may be used. In some embodiments, computer system 600 may implement the stored program components of a mail client. The mail client is a mail browsing application such as APPLE (registered trademark) MAIL (registered trademark), MICROSOFT (registered trademark) ENTOURAGE (registered trademark), MICROSOFT (registered trademark) OUTLOOK (registered trademark), MOZILLA (registered trademark) THUNDERBIRD (registered trademark), and the like. May be

Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with this disclosure. Computer-readable storage media refers to any type of physical memory that can store information or data readable by a processor. Accordingly, a computer-readable storage medium includes instructions for one or more processors to perform, including the instructions to cause the processor to perform steps or stages consistent with the embodiments described herein. Can be stored. The term "computer-readable medium" is to be understood as including tangible material and excluding carrier waves and transitory signals, ie non-transitory. Examples include random access memory (Random Access Memory, RAM), read-only memory (Read-Only Memory, ROM), volatile memory, non-volatile memory, hard drive, CD ROM, DVD, flash drive, disk, and others. , Any known physical storage medium.

One embodiment of the present disclosure may be used in fields such as automobiles and industrial control, which need to meet functional safety standards as well as improving processing capacity.

The embodiment of the present disclosure enhances reliability by suppressing interference with safe operation of a highly reliable entity due to adverse effects caused by non-safety conforming system components.

Embodiments of the present disclosure reduce the cost of designing and developing available components.

One embodiment of the present disclosure includes safety firmware and verification techniques to enhance refinement of disparate software and hardware components.

The described acts may be implemented as a method, system or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The operations described may be implemented as code carried on a "non-transitory computer-readable medium." There, a processor may read and execute the code from the computer-readable medium. The processor is at least one of a microprocessor and a processor capable of processing and executing queries. Non-transitory computer readable media include magnetic storage media (eg, hard disk drives, floppy disks, tapes, etc.), optical storage (CD-ROM, DVD, optical disks, etc.), volatile memory devices and non-volatile memory devices. Other media (eg, EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash memory, firmware, programmable logic, etc.) may be included. In addition, non-transitory computer-readable media includes all computer-readable media except transitory media. Code implementing the described operations may also be implemented in hardware logic (eg, integrated circuit chips, programmable gate arrays (Programmable Gate Array, PGA), application specific integrated circuits (ASIC), etc.).

Still further, code implementing the described operations may be implemented in a "transmission signal," which is propagated through space or over a transmission medium such as optical fiber, copper wire, or the like. Good. The transmission signal encoded with the code or logic may further include a wireless signal, satellite transmission, radio wave, infrared signal, Bluetooth, and the like. The code or logic encoded transmission signal can be transmitted by a transmitting station and received by a receiving station. The code or logic encoded in the transmitted signal may be decoded at the receiving and transmitting stations or the receiving and transmitting devices and stored in hardware or non-transitory computer readable media. An "article of manufacture" includes non-transitory computer readable media, hardware logic, and/or transmitted signals, in which code may be implemented. The device on which the code implementing the described embodiments of the operations is encoded may include computer-readable media or hardware logic. Of course, one of ordinary skill in the art can make many changes to this configuration without departing from the scope of the present invention, and the article of manufacture will include any suitable information transmission media known in the art. You will recognize that it is good.

The terms "an embodiment", "embodiment", "embodiments", "embodiments", "embodiments", "one or more" "Embodiment", "some embodiments", and "one embodiment" mean "one or more, but not all embodiments of the invention," unless expressly specified otherwise. ..

The terms “including”, “comprising”, “having” and variations thereof mean “including but not limited to”, unless expressly specified otherwise.

The listing of the listed items does not imply that any or all of the listed items are mutually exclusive, unless expressly specified otherwise.

The terms “a”, “an”, and “the” mean “one or more”, unless expressly specified otherwise.

A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments of the present invention.

Where a single device or article is described herein, more than one device/article (whether or not they work together) is used instead of a single device/article. It will be easy to see what you get. Similarly, if more than one device or article is described herein (whether or not they work together), a single device/item instead of more than one device/item is described. It will be readily appreciated that articles may be used, or different numbers of devices/articles may be used instead of the number of devices or programs shown. The functions and/or features of the device may alternatively be embodied by one or more other devices not explicitly described as having such features/features. Therefore, other embodiments of the invention need not include the device itself.

The operation shown in FIG. 5 indicates a specific event that occurs in a specific order. In another embodiment, the particular operations may be performed, modified, or deleted in a different order. Furthermore, steps may be added to the above logic and still be compatible with the described embodiments. Further, the acts described herein may occur sequentially, or particular acts may be processed in parallel. Still further, the operations may be performed by a single processing unit or a distributed processing unit.

Finally, the words used in the specification have been selected primarily for readability and instructional purposes and have been selected to clearly describe the invention or to delineate the scope of the invention. It may not exist. Therefore, it is intended that the scope of the invention be limited not by this detailed description, but by any claims issued in the application herein. Accordingly, the disclosure of embodiments of the invention is intended to exemplify, without limitation, the scope of the invention as set forth in the claims below.

Although various aspects and embodiments are disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, the true scope and spirit of which is set forth by the following claims. ..

100...Environment, 101...Embedded ECU system, 103...I/O interface, 105...Memory, 107...Processor, 107 _1N ...Processor of first set of processors, 107 _2N ...Processor of second set of processors, 113 ... system resource, 115 _1N ... first processor set security module, 115 _2N ... second processor set security module, 200 ... data, 201 ... divided data, 203 ... security setting data, 205 ... Verification data, 207... Other data, 209... Module, 211... Division module, 213... Extraction module, 215... Transmission module, 217... Other module, 301... Processor, 302... Processor, 303... Safety module, 305... Module for division, 307... Extraction module, 309... First application, 311... Second application, 312... Application, 313... Safety module, 315... Verification module, 316... Safety verification engine, 317... SoftIp, 318 ... safety middleware, 600... computer system, 601... I/O interface, 602... processor, 603... network interface, 604... storage interface, 605... memory, 606... user interface, 607... operating system, 608... web browser

Claims

An embedded ECU system comprising multiple processors,
A partition module for partitioning the plurality of processors into a first set of processors and a second set of processors;
An extraction module for extracting a safety setting for the first set of processors;
The safety settings are generated during the split,
The security settings of the first set of processors are verified based on trusted security settings;
The first set of processors access system resources based on a result of the verification,
Embedded ECU system with multiple processors.
The first set of processors receives the security settings from the second set of processors and sets the security settings for each memory management unit (MMU) based on the partitioning;
The built-in ECU system according to claim 1.
A transmitter module for transmitting the security settings to the second set of processors;
The built-in ECU system according to claim 1.
A verification external to the embedded ECU system for verifying the safety setting of the first set of processors based on the trusted safety setting of the second set of processors. With modules,
The built-in ECU system according to claim 1.
An external verification associated with the embedded ECU system for verifying the safety setting of the first set of processors based on the trusted safety setting of the second set of processors. With modules,
The built-in ECU system according to claim 1.
The first set of processors is verified by comparing the security settings to the trusted security settings of the second set of processors,
The built-in ECU system according to claim 1.
The security setting value includes a range that allows access to the first set of processors, and the trusted security setting value includes a range that allows access classified by a plurality of levels.
The built-in ECU system according to claim 1.
Each processor of the first set of processors is a low reliability processor and each processor of the second set of processors is a high reliability processor,
The built-in ECU system according to claim 1.
The embedded ECU system according to claim 1 executes the instance of the safety module at the highest privilege level.
An access unit associated with the embedded ECU system for providing access to the first set of processors based on a result of the verification;
The built-in ECU system according to claim 1.
The embedded ECU system of claim 1 includes providing access to a requested memory location to the first set of processors based on the results of the verification.
The embedded ECU system according to claim 1 includes notifying the first set of processors of a writable and unrewritable status on a memory location based on the result of the verification.
A method for managing critical mixed functionality for heterogeneous asymmetric systems, comprising:
Dividing the plurality of processors into a first set of processors and a second set of processors by means of an embedded ECU system;
Extracting, by the embedded ECU system, a safety setpoint for the first set of processors;
The safety settings are generated during the split,
The security settings of the first set of processors are verified based on trusted security settings;
The first set of processors access system resources based on a result of the verification,
A method for managing mixed critical functionality for heterogeneous asymmetric systems.
The first set of processors receives the security settings from the second set of processors and sets the security settings for each memory management unit (MMU) based on the partitioning;
The method of claim 13.
Further comprising sending the security settings to the second set of processors,
The method of claim 13.
A verification external to the embedded ECU system for verifying the safety setting of the first set of processors based on the trusted safety setting of the second set of processors. With modules,
The method of claim 13.
An external verification associated with the embedded ECU system for verifying the safety setting of the first set of processors based on the trusted safety setting of the second set of processors. With modules,
The method of claim 13.
Validating the security settings of the first set of processors comprises comparing the security settings to the trusted security settings of the second set of processors.
The method of claim 13.
The security setting value includes a range that allows access to the first set of processors, and the trusted security setting value includes a range that allows access classified by a plurality of levels.
The method of claim 13.
Each processor of the first set of processors is a low reliability processor and each processor of the second set of processors is a high reliability processor,
The method of claim 13.
Further comprising executing an instance of a safety module at the highest privilege level by the embedded ECU,
The method of claim 13.
14. The method of claim 13, further comprising providing the access to a requested memory location to the first set of processors based on the result of the verification.
Further comprising notifying the first set of processors of writable and unwritable status on a memory location based on the result of the verification,
The method of claim 13.
An access unit associated with the embedded ECU system for providing access to the first set of processors based on a result of the verification;
The method of claim 13.