GB2560780A - A method to monitor program flow for multitasking real-time embedded software with ASIL rating - Google Patents
A method to monitor program flow for multitasking real-time embedded software with ASIL rating Download PDFInfo
- Publication number
- GB2560780A GB2560780A GB1713459.4A GB201713459A GB2560780A GB 2560780 A GB2560780 A GB 2560780A GB 201713459 A GB201713459 A GB 201713459A GB 2560780 A GB2560780 A GB 2560780A
- Authority
- GB
- United Kingdom
- Prior art keywords
- task
- runnable
- tasks
- asil
- signature
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3466—Performance evaluation by tracing or monitoring
- G06F11/3476—Data logging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0715—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
- G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0751—Error or fault detection not based on redundancy
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0796—Safety measures, i.e. ensuring safe condition in the event of error, e.g. for controlling element
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3017—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/805—Real-time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/865—Monitoring of software
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Mathematical Physics (AREA)
- Debugging And Monitoring (AREA)
Abstract
A method to monitor program flow of runnable processes or tasks in a multitasking real time system, the processes or tasks having different or mixed automotive safety integrity level (ASIL) ratings. Temporal and spatial freedom from interference is maintained. The method creates one or more safety goals 301-303 having different ASIL ratings on a single core processer. A plurality of runnable processes RX_Y_Zms_N are created per safety goal and memory is split and allocated such that runnable processes with the same ASIL share the same memory part. Runnable processes are allocated to tasks T1-T8 and each task is allocated a fixed time period Zms for repetition. Task are prioritized and a calling order of tasks is determined. A question generated by a monitoring module is sent to a task to detect abnormalities in runnable/task execution. A unique signature is assigned per question at the receiving task and the signature is updated as each runnable/task is executed. A final signature is derived following execution of all the tasks and is sent to the monitoring module, where a comparison of the received answer with a predefined time and expected result occurs, and a safe state is commanded when a mismatch occurs.
Description
(54) Title of the Invention: A method to monitor program flow for multitasking real-time embedded software with ASIL rating
Abstract Title: Monitoring program flow for multitasking real-time embedded software with mixed automotive safety integrity level (ASIL) ratings (57) A method to monitor program flow of runnable processes or tasks in a multitasking real time system, the processes or tasks having different or mixed automotive safety integrity level (ASIL) ratings. Temporal and spatial freedom from interference is maintained. The method creates one or more safety goals 301-303 having different ASIL ratings on a single core processer. A plurality of runnable processes RX_Y_Zms_N are created per safety goal and memory is split and allocated such that runnable processes with the same ASIL share the same memory part. Runnable processes are allocated to tasks T1-T8 and each task is allocated a fixed time period Zms for repetition. Task are prioritized and a calling order of tasks is determined. A question generated by a monitoring module is sent to a task to detect abnormalities in runnable/task execution. A unique signature is assigned per question at the receiving task and the signature is updated as each runnable/task is executed. A final signature is derived following execution of all the tasks and is sent to the monitoring module, where a comparison of the received answer with a predefined time and expected result occurs, and a safe state is commanded when a mismatch occurs.
300 z
| Task Rate | SG1 B (301) | SG2 C (302) | SG3 D (303) |
| 2ms | - R1JZ2nis__i ! R1 B 2ms 2 H RZB__2-s__„3 | ||
| 2 R3..D....2ms..4 )5 R3_D__2ms_5 | |||
| p R2 C 2ms 6 | |||
| 4ms | 5 R3 D 4ms 1 I R3 D 4ms 2 | ||
| 2 R1 B 4ms 3 W ... ...... R1_B_4ms_4 | |||
| R2jC..4ms....5 | |||
| 8ms | £ R1 B 8ms 1 §, R1_B_8ms__2 | ||
| $ R3 D Sms 3 )5 R3_D_8ms__4 |
p
CL
FIG.3d
At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy.
1608 18
Creating a number of runnabies per safety goal to achieve functional safety in an E/E system
1608 18
Iplitting the memory into at least one part to ensure spatial freedom from interference
Assigning fixed time period for ail the tasks with mixed AS IL rating
Assigning calling order for each individual task and setting task priority based on the calling sequence
Generating at least one question by a monitoring module to be sent to a particular task (T4) running on a function controller
1608 18
Initializing a signature variable to monitor the execution of ail the tasks upon receiving the question by the functional controller
| 1 | P |
| Combining signatures from each individual task to form a final signature when the task (T4) is activated again and determining an answer | |
| Ί Receiving the answer ar answer is received with! matches with the | P id checking whether the n a predefined time and 5 expected result |
| 1 | P |
Commanding a safe state when the answer received by the monitoring module is not within the predefined time or does not match with the
4/11
300
1608 18
Z
| SG1_B (301) | SG2J3 (302) | SG3__D (303) |
| Safety Goal 1 ASILB | Safety Goal 2 ASILC | Safety Goal 3 ASILD |
co ο
co co
Ο co
CNi
Ο co
Csi
V- C\i co ω co co Ε Ε Ε <N|C\!|(N| CO CO CO __ J J__ J CL CL CL
| •\r io | v“ CM a a | |
| 3 ΐ ω ω | 1 3 ω co | |
| Ε Ε | p £: | |
| CM CM a a | 'Tf I j | |
| a 3 Q Q a g | 3 a Q Q j ! | |
| 9 3 CO CO | I 1 CO co | |
| CL CL | CL CL | |
| 2>|se± | l7>)se± | |
| wo j a | CD i | v~ CM a a |
| 3 3 ω ω | 03 | 3 3 co ω |
| Ε Ε | E | Ε E |
| CM CM a a | CM I | j 1 |
| 3 a Q Q a a | 3 o | I 3 O Q a a |
| 3 a co co | 3 CM | 1 3 co co |
| CL CL | QC | CL CL |
| ει |
co
v) v} E E
M 'sf ΕΏ 03
CL CL
WO
I co
E 'sf
I o
I
C\!
CL v- CM cJ «J E E
CO 00 i I
03 I I
CL CL
Ο co
| co | ||
| vt | co | V) |
| E | E | E |
| CM | CM | CM |
| 03 i | 03 1 | 03 |
| i | 3 | , |
| CL | #v* Lu | CL |
^se±
| CO a | 'sf |
| ω | co |
| E | c c |
| CO I | co |
| 3 Q a | Q |
| 1 co | co |
| ££ | CL |
co Tf I I co co
E E co co i f Q Q i f co co CL CL
CO MT to so E E
M 'sf I I
ΕΏ 03
CL CL v~ CM «5 CO
E E co co I I 03 03 ^J.J CL CL
S>jse±
ZW1
6/11
1608 18
1608 18
1608 18
1608 18
1608 18
11/11
1608 18
| 'sT ω | Ύ w E Q I to CC | gC BBI «X» XX> XXI BBC BBI «X» V « Var_D_4ms__PFC = func(Var_D_4ms_PFC,CRC_Table! R3_D_4ms_1_StartKey) /‘Start of runnable impiemenTatrdn^/ /‘End of runiable impiementaft©^/ Var D 4ms RFC = func(Var D 4ms PFC.CRC Table, R3 D 4ms 1 EndKey) |
| CN I « E Q I CO CC | ♦.......! Var_D_4ms_PFG = func(Var„D„4ms_PFC!CRC„Table, R3__D__4ms__2__StartKey) /‘Start of runnable ImplemenTatron^/ /*End of runMable implementaft©^/ Var D 4ms RFC = func(Var D 4ms PFC,CRC Table. R3 D 4ms 2 EndKey) ......... | |
| | Task 5 | co I « E m I s | V * Var__B_4ms__PFC = fune(Var__B__4ms_PFC,CRC„Tab!e, R1__D__4ms__1__StartKey) /‘Start of runnable impiemenTatrdn^/ /‘End of runMable implementaft®^/ Var B 4ms RFC = func(Var B 4ms PFC.CRC Table, R1 D 4ms 1 EndKey) |
| Λ w E co I 5 | V.......1 Var_B__4ms__PFC = funt(Var___B__4ms__PFC,CRC__Table, R1_B__4ms_4_StartKey) /‘Start of runnable implemenlatKTn*/ /‘End of runMable impiementafr©^/ Var B 4ms RFC = func(Var B 4ms PFC,CRC Table, R1 B 4ms 4 EndKey) & <» XX, OB. «X» XX, BBC <X> J |
FIG.3h
A method to monitor program flow for multitasking real-time embedded software with mixed ASIL rating [0001] PREAMBLE TO THE DESCRIPTION:
[0002] The following specification particularly describes the invention and the manner in which it is to be performed:
[0003] Technical field of the invention [0004] The present invention relates to a method to monitor program flow for multitasking real-time embedded software with mixed Automotive Safety Integrity Level (ASIL) rating.
[0005] Background of the invention [0006] In automotive electrical/electronic (E/E) system development, we have witnessed a clear trend that an increasing number of functions have been integrated into the state-of-the-art electronic control unit with increasing computing power. Both the customers and Original Equipment Manufacturer (OEM) have benefited from this trend with more features available and greater user-experience as well as lower cost in both development and production phases.
[0007] Since conventional single core processors can only execute one task at a time, real time operating systems supporting multitasking have been widely used in various applications. By rapidly switching between different tasks based on their priority and status, E/E systems could achieve multiple functionalities (control, diagnostics, monitor, and service) at the same time preserving both predefined timing and functional requirements. Besides Central Processing Unit (CPU) timing, other critical computation infrastructures like memory and communication buses also need to be shared to achieve desired functionalities within modem embedded computing architecture. Safety is always the most critical concern for automotive OEMs/suppliers, government regulators, and millions of customers. As more and more E/E systems including hardware and software have been integrated into modern passenger vehicles, it has enabled safer and more fuel-efficient vehicles for decades, as well as plays a crucial role in the development of electric and hybrid vehicles in recent decades. Besides those well-known benefits, the entire automotive industry is also well aware of risks and hazards caused by the malfunction of E/E systems regarding the E/E systems related to the vehicle dynamics/powertrain. To address safety concerns in the E/E system product development, International standard (ISO 26262) and standardized safety concept (E-GAS 3 Level Monitoring Concept) is widely adapted by the automotive industrial. As shown in FIG 1, the conventional safety architecture for automotive E/E system comprises three levels of monitoring. The level one controller function (101) contains normal functionality including torque control (combustion engine control, e-motor control, and brake control) and sensor diagnostics (air mass sensor, current sensor, high voltage sensor). The level two controller function (102) detects the defective level 1 behavior and in case of detecting Level one functional controller fault, system error reactions are triggered. The level three controller function (103) ensures the proper execution of Level 2 monitoring, which tests the correctly executed program during the question-answer process and performs processor integrity monitoring.
[0008] For example, in a typical electric motor control system using an inverter for the electric/hybrid powertrain, Level one controller function (101) contains a motor torque control algorithm based on driver input. The level one controller function (101) also includes the necessary diagnostics functionalities for current, voltage, and position sensors. In parallel, Level two controller function (102) is constantly monitoring the achieved motor torque controlled by Level one controller function (101) and comparing it with driver input. In case there are certain HW/SW issues causing Level one controller function (101) to command too high of a torque compared with driver input, a hazardous event could be caused called unintended acceleration, which shall be detected by the Level two monitoring function (102) which would be followed by a proper shut down reaction. This level three monitoring function (103) requires an additional monitor level, simply called Level three, to constantly check Level two execution status through a program flow monitoring method to ensure this critical Level two safety mechanism is always ready to protect our drivers.
[0009] Considering certain E/E systems related to vehicle safety, a new challenge is emerging along with this trend due to mixing functions/runnable with different safety levels in the same electronic control unit sharing the same computing resources, and how to design Level three to correctly execute Level two monitoring. Unfortunately, the complexity of the algorithm and interfaces of the functions/runnables in the modem E/E systems keeps increasing significantly on every new product/vehicle, therefore it is technically and economically impossible to develop all functions/runnables with lower safety levels or non-safety relevant functions/runnables as the same standard as the ones with higher safety level designations. In general, co-existence of functions/runnables with different safety levels is inevitable.
[0010] For instance, the European patent document EP2513456A1 (referred herein as ‘456) discloses a monitoring computer for monitoring a functional computer on which three program modules arc used to influence the drivability of the motor vehicle. Here, the monitoring computer is independent from the functional computer and monitors the functional computer by means of a questionnaire response process. However, the document ‘456 does not disclose any aspects of monitoring program flow in a multitasking real time E/E systems containing software components with different ASIL ratings.
[0011] Hence, there exists a need for a method that achieves temporal freedom from interference through program flow monitoring for multitasking real time E/E systems containing software components with different ASIL ratings while maintaining spatial freedom from interference.
[0012] Summary of the invention [0013] The present invention overcomes the drawbacks of the prior art by providing a method to monitors program flow of runnable/tasks in a multitasking real time
E/E systems with different ASIL ratings while maintaining temporal and spatial freedom from interference. For this purpose, the method generates at least one question by a monitoring module to be sent to any particular task namely task running on a function controller to detect abnormalities in runnable/task execution. Further, a unique signature is assigned per question at the task and the signature is updated as each runnable/task is executed and a final signature is derived at particular task (that has received the question) at the end of execution of all the tasks to generate final answer to be sent to the monitoring module. The monitoring module compares the received answer within a predefined time and expected result and commands a safe state when a mismatch occurs.
[0014] In accordance to another embodiment of the present invention, when the answer is received by the monitoring module is not within the predefined time or does not match with the expected result a default safe state is commanded to shut down the vehicle.
[0015] In accordance to one embodiment of the present invention, the memory is split into at least one part to ensure spatial freedom from interference as the runnable with the same ASIL should share the same memory. Further to achieve temporal freedom from interference and to ensure that the runnables are executed in fixed order, runnables are allocated to certain tasks with a predefined calling order such that the runnables inside the task is run in a top to bottom manner.
[0016] In accordance to one embodiment of the present invention, the function controller comprises the runnables/tasks required to achieve safety goal in gasoline and diesel engine control unit.
[0017] Thus, the method of the present invention achieves temporal freedom from interference through program flow monitoring for multitasking real time E/E systems containing software components with different ASIL ratings while maintaining spatial freedom from interference.
[0018] Brief description of the drawings:
[0019] The foregoing and other features of embodiments will become more apparent from the following detailed description of embodiments when read in conjunction with the accompanying drawings. In the drawings, like reference numerals refer to like elements.
[0020] FIG 1 illustrates conventional safety architecture (source:
concepts, from page 38 to page 39) for automotive E/E system, in accordance to one or more embodiment of the present invention.
[0021] FIG 2 illustrates a method to monitor program flow for multitasking realtime embedded software with mixed ASIL rating, in accordance to one or more embodiment of the present invention.
[0022] FIG 3 - FIG 3h illustrates a process for monitoring multitasking real-time embedded software with mixed ASIL rating, in accordance to one or more embodiment of the present invention.
[0023] Detailed description of the invention:
[0024] Reference will now be made in detail to the description of the present subject matter, one or more examples of which are shown in figures. Each example is provided to explain the subject matter and not a limitation. Various changes and modifications obvious to one skilled in the art to which the invention pertains are deemed to be within the spirit, scope and contemplation of the invention.
[0025] While the present invention has been described with respect to certain embodiments, it will be apparent to those skilled in the art that various changes and modification may be made without departing from the scope of the invention as defined in the following claims.
[0026] The present invention relates to a method to monitor program flow for multitasking real-time embedded software with mixed ASIL rating. The method to monitors program flow of runnable/tasks in a multitasking real time E/E systems with different ASIL ratings while maintaining temporal and spatial freedom from interference.
[0027] FIG 2 and FIG 2a illustrates a method to monitor program flow for multitasking real-time embedded software with mixed ASIL rating, in accordance to one or more embodiment of the present invention. The method to monitor program flow for multitasking real-time embedded software with mixed automotive safety integrity level (ASIL) rating comprises the steps of creating one or more safety goal with different ASIL rating on a single core processor (300) at step 201. For instance, let us assume that the method creates three safety goals safety goal 1 with ASIL B rating (SG1_B, 301), safety goal 2 with ASIL C rating (SG2_C, 302) and safety goal 3 with ASIL D rating (SG3_D, 303). Further, a number of runnables are created per safety goal at step 202 to achieve functional safety in an electrical/electronic system. For instance, two runnables “R2_C_2ms_6” and “R2_C_2ms_5” are created to realize the safety goal 2. Here “R2_C” stands for “Runnable derived from Safety Goal 2 inheriting ASIL C”. “2ms_5” represents the period (2ms) and sequence (to be called after R3_D_2ms_4 and before R2_C_2ms_6) about how this runnable shall be executed.
[0028] At step 203, the memory is split into at least one part to ensure spatial freedom from interference as the runnable with the same ASIL should share the same memory. Further to achieve temporal freedom from interference and to ensure that the runnables are executed in fixed order, runnables are allocated to certain tasks (namely Task 1 (Tl), Task 2 (T2), Task 3 (T3), Task 4 (T4), Task 5 (T5), Task 6 (T6), Task 7 (T7) and Task 8 (T8)) with a predefined calling order such that the runnables inside the task (Tl, T2, T3, T4, T5, T6, T7 and T8) can run in a top to bottom manner.
Γ0029] At step 204, fixed time period is assigned for all tasks (Tl, T2, T3, T4, T5, T6, T7, T8) with mixed ASIL rating so as to achieve temporal freedom from interference. At step 205, calling order is assigned for each individual task (Tl, T2, T3, T4, T5, T6, T7 and T8) and task priority is set based on the calling sequence.
[0030] However, there are some problems associated with the assigning fixed time period for runnables inside the task. For instance, in case when certain runnables in the high priority task takes a longer time to execute then the lower priority tasks are executed later than the usual. In another case, OS task switching/scheduler does not work properly such that the execution order is wrong. Further, there may be chances that certain runnables/tasks could be terminated too early due to abnormal sequence of instruction execution.
[0031] Thus, in order to detect abnormal behaviors in the runnable execution regarding temporal freedom from interference there exists a need to monitor runnables execution for a multitasking system with mixed AS IL rating. For this purpose, at least one question is generated by a separate monitoring module (304) to be sent to a particular task namely task 4 (T4) running on a function controller (305) at step 206 so as to detect any abnormalities in runnable execution. The task (T4) upon receiving the question initializes a signature variable to monitor the execution of all the tasks at step 207 by the functional controller (305). From this point, the program flow monitoring algorithms run separately and update the separate signatures with a cyclic redundancy check (CRC) table. The separate signatures used in the program flow monitoring of all these tasks is combined together to form a final signature when the particular task (T4) is activated again. Further, an answer is determined using the final signature and is send back to the monitoring module at step 208.
[0032] In accordance to one embodiment of the present invention, the signature is initialized to a predefined unique value per question at Task 4 and after initialization, all the program flow signatures is updated as the CPU executes each runnable/task in the predefined order. Since all those signatures will be updated by a pair of unique Start/EndKey, a set of unique final signatures for all the tasks is obtained per question once the next Task 4 gets executed and the final signatures is combined at Task 4 to generate the final answer.
[0033] In accordance to one embodiment of the present invention, the function controller (305) executes all runnables/tasks required to achieve safety goal in gasoline and diesel engine control units.
[0034] The monitoring module (304) upon receiving the answer checks whether the answer is received within a predefined time and matches with the expected result at step 209 based on the question sent by the monitoring module (304) to the function controller (305) and then commands a safe state when the answer received by the monitoring module (304) is not within the predefined time or does not match with the expected result at step 210. Thus, during normal execution runnable execution condition, the monitoring module (304) receives the answer within the predefined time and also the received answer matches with the expected result.
[0035] However, when the answer is received by the monitoring module (304) is not within the predefined time and/or the received answer does not match with the expected result a default safe state is commanded to shut down the vehicle.
[0036] FIG 3-FIG 3h illustrates a process for monitoring multitasking real-time embedded software with mixed ASIL rating, in accordance to one or more embodiment of the present invention.
[0037] As shown in FIG 3, three safety goals safety goal 1 with ASIL B rating (SG1_B, 301), safety goal 2 with ASIL C rating (SG2_C, 302) and safety goal 3 with ASIL D rating (SG3_D, 303) are created. Further, a number of runnables are created per safety goal say SG1_B (301), SG2_C (302) and SG3_D (303) (as shown in FIG 3a) to achieve functional safety in an electrical/electronic system. For instance, two runnables “R2_C_2ms_6” and “R2_C_2ms_5” are created to realize the safety goal 2. Here “R2_C” stands for “Runnable derived from Safety Goal 2 inheriting ASIL C”. “2ms_5” represents the period ‘2 milliseconds’ (2ms) and sequence (to be called after R3_D_2ms_4 and before R2_C_2ms_6) about how the runnable will be executed.
[0038] However, in order to achieve spatial freedom from interference only runnable with the same ASIL should share the same memory. For this purpose, the memory is split into three parts (as shown in FIG 3b) to ensure spatial freedom from interference as the runnable with the same ASIL should share the same memory. Further, the runnables are allocated to certain tasks namely Task 1 (Tl), Task 2 (T2), Task 3 (T3), Task 4 (T4), Task 5 (T5), Task 6 (T6), Task 7 (T7) and Task 8 (T8) (as shown in FIG 3c). Thus, three tasks namely Task 1 (Tl), Task 2 (T2) and Task 3 (T3) are created for all 2 ms runnable per ASIL B/C/D rating. Similarly, three tasks Task 4 (T4), Task 5 (T5) and Task 6 (T6) are created for all 4ms runnables with ASIL B/C/D rating. Further, two tasks Task 7 (T7) and Task 8 (T8) are created for all 8ms runnables per ASIL B/D rating. Further in order to achieve temporal freedom from interference and to ensure that the runnables are executed in fixed order, with a predefined calling order the runnables inside the task (Tl, T2, T3, T4, T5, T6, T7 and T8) are run in a top to bottom manner as shown in FIG 3d.
[0039] FIG 3e is an illustrative time chart describing how the task priority and switching are performed to achieve spatial and temporal interference assuming that CPU throughput is acceptable, OS task switching is always working properly and instruction execution always follows the desired order.
[0040] However, there are some problems associated with assigning fixed time period for runnables inside the task, as in certain cases, runnables in the high priority task say task 3 takes a longer time to execute thereby causing low priority tasks task 4, task 5 and task 6 to be activated and executed later than the usual. In yet another case, OS task switching/scheduler does not work properly such that the execution order is wrong. Further, there may be chances that certain runnable/tasks could be terminated too early due to abnormal sequence of instruction execution.
[0041] Thus, in order to detect abnormal behaviors in the runnable execution regarding temporal freedom from interference there exist a need to monitor runnable execution for a multitasking system with mixed ASIL rating. For this purpose, at least one question is generated by a separate monitoring module (304) (as shown in FIG 3f) to be sent to a particular task namely task 4 (T4) running on a function controller (305) at step 206 so as to detect any abnormalities in runnable execution. The task (T4) upon receiving the question initializes a signature variable to monitor program flow in all 2ms/4ms/8ms tasks at step 207 by the functional controller (305). From this point, the program flow monitoring algorithms run separately on all three branches and update the separate signatures with a cyclic redundancy check (CRC) table. Further, 4ms later when task (T4) is activated and running again, the separated signatures used in the program flow monitoring on all these three branches is combined together to form a final signature in T4 and an answer is determined from the combined program flow chart and is the sent back to the monitoring module (304).
[0042] The monitoring module (304) upon receiving the answer checks whether the answer is received within a predefined time and matches with the expected result based on the question sent by the monitoring module (304) to the function controller (305). During a normal runnable execution condition, the monitoring module (304) receives the answer within the predefined time and also the received answer matches with the expected result.
[0043] However, when the answer is not received by the monitoring module (304) within the predefined time and/or the received answer docs not match with the expected result, a default safe state is commanded to shut down the vehicle.
[0044] FIG 3g and FIG 3h illustrates signature updating process for all 4ms tasks in a step wise manner, in accordance to one or more embodiment of the present invention.
[0045] FIG3g illustrates the signature updation process for all the 4ms tasks (Task 4 (T4), Task 5 (T5) and Task 6 (T6)). Here, the functional controller (305) is configured to read questions from the monitoring module (304) interface for every 4ms and the 4ms signature Var_D_4ms_PFC is initialized based on the question. Here PFC stands for program flow check. Thus for each question from the monitoring module (304), Var_D_4ms_PFC is initialized to a unique signature as shown below:
Var_D_4ms_PFC = Initial_Table [Questions] [0046] For instance at the beginning of task 4 (T4), the 4ms signature Var_D_4ms_PFC is updated in task 4 (T4) and the updated Var_D_4ms_PFC is sent to task 5 (T5). Further, details of signature updation sequence of task 4 and task 5 is shown in FIG 3h.
[0047] As shown in FIG 3h, in the beginning of the runnable R3_D_4ms_l, the 4ms signature Var_D_4ms_PFC is updated together with a constant CRC_Table and unique key R3_D_4ms_l_StartKey as shown below:
Var_D_4ms_PFC = Crc_Table [ Var_D_4ins_PFC©R3_D_4ms_l_S tart Key] © (Var_D_4ms_PFC »8) [0048] Here ©denotes Bitwise XOR operation and » denotes right shift operation. Further, at the end of the runnable R3_D_4ms_l, the 4ms signature Var_D_4ms_PFC is updated again with the same CRC_Table and another unique key R3_D_4ms_l_EndKey as shown below:
Var_D_4ms_PFC = Crc_Table [Var_D_4ms_PFC©R3_D_4ms_l_EndKey] © (Var_D_4ms_PFC »8) [0049] Similarly, the 4ms signature Var_D_4ms_PFC is updated again at the beginning and end of the runnable R3_D_4ms_2. Thus for each question from the monitoring module there is a unique signature Var_D_4ms_PFC after the CPU successfully and completely executes runnable Task 4 containing R3_D_4ms_l and R3_D_4ms_2 in the right order.
[0050] Similarly, task 5 contains two runnable Rl_B_4ms_3 and Rl_B_4ms_4 and the runnable Rl_B_4ms_3 is initialized to the 4ms signature Var D 4ms PFC obtained at the end of the runnable R3_D_4ms_2 in task 4. However, to achieve spatial Freedom from Interference, it is not allowed to write an ASIL D variable Var_D_4ms_PFC in an ASIL B task. Therefore the signature update algorithm in the beginning of runnable Rl_B_4ms_3 as follows:
Var_B_4ms_PFC = Crc_Table [Var_D_4ms_PFC©Rl_B_4ms_3_StartKey] © (Var_B_4ms_PFC »8) [0051] Further, at the end of the runnable Rl_B_4ms_3, the 4ms signature Var_D_4ms_PFC is updated again with CRC_Table and another unique key Rl_B_4ms_3_EndKey as shown below:
Var_B_4ms_PFC = Crc_Table [Var_B_4ms_PFC©Rl_B_4ms_3_EndKey] θ (Var_B_4ms_PFC »8) [0052] Thus, the 4ms signature Var_B_4ms_PFC is updated again at the end of runnable Rl_B_4ms_3 and Rl_B_4ms_4 (as shown in FIG 3h). The updated 4ms signature Var_B_4ms_PFC is sent to task 6. The 4ms signature Var_C_4ms_PFC is updated again in task 6 as the last 4ms task, and a final 4ms task signature is combined in task 4 the next time it get executed. Here, as long as all 4ms tasks runnable could finish successfully and completely within 4ms in the correct order, we shall always get the same signature at the end of Task 6 per each question from the monitoring module (304).
[0053] In accordance to one embodiment of the present invention, the 2ms signature Var_2ms_B_PFC and the 8ms signature Var_8ms_B_PFC is initialized to a predefined unique value per question at Task 4 and after initialization all 2ms/4ms/8ms program flow signatures is updated as the CPU executes each runnable/task in the predefined order. Since all those signatures will be updated by a pair of unique Start/EndKey such as R3_D_4ms_l_Startkey and R3_D_4ms_l_EndKey, a set of unique final signatures for 2ms/4ms/8ms tasks is obtained per question once the next Task 4 gets executed and the final signatures is combined at Task 4 to generate the final answer.
[0054] Thus, in case any runnable/task is not executed successfully and completely in the predefined order and period, the monitoring module (304) does not get a right answer and a safe command to shut down the vehicle is expected from the monitoring module.
[0055] Thus in accordance to one embodiment of the present invention, the memory is split into at least one part to ensure spatial freedom from interference as the runnable with the same ASIL should share the same memory. Further to achieve temporal freedom from interference and to ensure that the runnables are executed in fixed order, runnables are allocated to certain tasks with a predefined calling order such that the runnables inside the task is run in a top to bottom manner.
[0056] Thus the method of the present invention achieves temporal freedom from 5 interference through program flow monitoring of runnable/tasks in a multitasking real time E/E systems with different AS IL ratings while maintaining spatial freedom from interference.
[0057] While the present invention has been described with respect to certain embodiments, it will be apparent to those skilled in the art that various changes and modification may be made without departing from the scope of the invention as defined in the following claims.
[0058] Claims:
Claims (4)
1. A method to monitor program flow for multitasking real-time embedded software with mixed automotive safety integrity level (ASIL) rating comprising the steps of:
a) creating one or more safety goal (301, 302, 303) with different ASIL rating on a single core processor (300);
b) creating plurality of runnables per safety goal (301, 302, 303);
c) splitting memory into at least one part to ensure spatial freedom from interference as the runnable with the same ASIL should share the same memory;
d) allocating runnables to certain tasks namely Task 1 (TI), Task 2 (T2), Task 3 (T3), Task 4 (T4), Task 5 (T5), Task 6 (T6), Task 7 (T7) and Task 8 (T8), and assigning fixed time period for all the tasks with mixed ASIL rating so as to achieve temporal freedom from interference;
e) calling order is assigned for each individual task and task priority is set based on the calling sequence;
f) generating at least one question by a monitoring module (304) to be sent to a particular task namely task 4 (T4) running on a function controller (305) to detect any abnormalities in runnable/task execution;
g) assigning a unique signature to a predefined unique value per question at task 4;
h) updating the signature at the end of each runnable/task in the predefined order;
i) combining the signature from all the tasks at task 4 to generate the final answer;
j) sending the final answer to the monitoring module (304) by the function controller (305); and
k) checking whether the answer is received within a predefined time, and matches with the expected result by the monitoring module (304); and
l) commanding a safe state when the monitoring module (304) does not receive the answer within the predefined time and matches with the expected result.
2. The method as claimed in claim 1, wherein when the received answer does not match with the expected result a default safe state is commanded by the monitoring module (304) to shut down the vehicle.
3. The method as claimed in claim 1, wherein the function controller (305) comprises plurality of runnables/tasks required for safety monitoring in gasoline and diesel engine control units.
4. The method as claimed in claim 3, wherein the plurality of tasks includes at least one of Task 1 (Tl), Task 2 (T2), Task 3 (T3), Task 4 (T4), Task 5 (T5), Task 6 (T6), Task 7 (T7) and Task 8 (T8).
Intellectual
Property
Office
Application No: GB1713459.4 Examiner: Dr Andrew Rose
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1713459.4A GB2560780A (en) | 2017-08-22 | 2017-08-22 | A method to monitor program flow for multitasking real-time embedded software with ASIL rating |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB1713459.4A GB2560780A (en) | 2017-08-22 | 2017-08-22 | A method to monitor program flow for multitasking real-time embedded software with ASIL rating |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| GB201713459D0 GB201713459D0 (en) | 2017-10-04 |
| GB2560780A true GB2560780A (en) | 2018-09-26 |
Family
ID=59996827
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB1713459.4A Withdrawn GB2560780A (en) | 2017-08-22 | 2017-08-22 | A method to monitor program flow for multitasking real-time embedded software with ASIL rating |
Country Status (1)
| Country | Link |
|---|---|
| GB (1) | GB2560780A (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8527139B1 (en) * | 2012-08-28 | 2013-09-03 | GM Global Technology Operations LLC | Security systems and methods with random and multiple change-response testing |
| US20160193973A1 (en) * | 2013-09-02 | 2016-07-07 | Robert Bosch Gmbh | Method for monitoring a component in a motor vehicle |
-
2017
- 2017-08-22 GB GB1713459.4A patent/GB2560780A/en not_active Withdrawn
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8527139B1 (en) * | 2012-08-28 | 2013-09-03 | GM Global Technology Operations LLC | Security systems and methods with random and multiple change-response testing |
| US20160193973A1 (en) * | 2013-09-02 | 2016-07-07 | Robert Bosch Gmbh | Method for monitoring a component in a motor vehicle |
Also Published As
| Publication number | Publication date |
|---|---|
| GB201713459D0 (en) | 2017-10-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9576137B2 (en) | Method and system for analyzing integrity of encrypted data in electronic control system for motor vehicle | |
| US10127161B2 (en) | Method for the coexistence of software having different safety levels in a multicore processor system | |
| US20230011677A1 (en) | Autonomous driving control system and control method and device | |
| US9610906B2 (en) | Vehicle control device | |
| EP3249534B1 (en) | Vehicle control device | |
| US10983519B2 (en) | Functional module, control unit for an operation assistance system, and device | |
| CN111338315A (en) | Virtual electronic control unit in AUTOSAR | |
| JP2015518605A (en) | Functional architecture patterns for safety applications | |
| US20050251308A1 (en) | Method and device for controlling the functional unit of a motor vehicle | |
| JP5541246B2 (en) | Electronic control unit | |
| CN108146250B (en) | Automobile torque safety control method based on multi-core CPU | |
| JP6007677B2 (en) | Safety control system and processor of safety control system | |
| US10585772B2 (en) | Power supply diagnostic strategy | |
| GB2560780A (en) | A method to monitor program flow for multitasking real-time embedded software with ASIL rating | |
| Brewerton et al. | Demonstration of automotive steering column lock using multicore autosar® operating system | |
| JP2010141654A (en) | Field communication system and method | |
| JP6434840B2 (en) | Electronic control unit | |
| US11097857B2 (en) | Multiple core motor controller processor with embedded prognostic/diagnostic capabilities | |
| KR101382109B1 (en) | Apparatus and method for middleware | |
| Panaroni et al. | Safety in automotive software: An overview of current practices | |
| US20240036878A1 (en) | Method for booting an electronic control unit | |
| JP2016084050A (en) | On-vehicle control apparatus | |
| Gandhi et al. | Techniques and measures for improving domain controller availability while maintaining functional safety in mixed criticality automotive safety systems | |
| US11422878B2 (en) | Control unit and method for operating a control unit | |
| Pasagadugula et al. | Effective approach for Redundancy in compliance with ISO26262 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) |