WO2023101094A1

WO2023101094A1 - Application method of arinc-based operating system for vehicle platform

Info

Publication number: WO2023101094A1
Application number: PCT/KR2021/019705
Authority: WO
Inventors: 박예슬
Original assignee: 주식회사 알티스트
Priority date: 2021-12-02
Filing date: 2021-12-23
Publication date: 2023-06-08
Also published as: KR20230082876A; KR102630359B1

Abstract

An application method of an ARINC-based operating system for a vehicle platform is disclosed. A vehicle operating system according to an embodiment disclosed herein comprises: an avionics application standard software interface (ARINC) 653-based operating system which is loaded in a vehicle; an automotive open system architecture (AUTOSAR) platform which is a software architecture loaded in a vehicle and includes an execution manager for generating a first-type execution management schedule; and a conversion interface which performs coupling between the ARINC 653-based operating system and the AUTOSAR platform and converts the fist-type execution management schedule into a second-type execution management schedule that can be used in the ARINC 653-based operating system.

Description

ARINC-based operating system application method for vehicle platform

Embodiments of the present invention relate to vehicle operating system technology.

ARINC (Avionics Application Standard Software Interface) 653 is a standard for developing application software for aviation, and defines an interface between a real-time operating system and an application program running on top of it. ARINC 653 is a Separation Kernel and is designed with the highest priority in ensuring safety, reliability, and real-time in any environment according to SKPP (Separation Kernel Protection Profile), a security requirement specification for separation kernels.

ARINC 653 manages the operation of partitions (execution units) based on process execution information defined in the configuration table. ARINC 653 defines a plurality of static modules in the configuration table, and changes and manages the modules to be executed according to the execution schedule. In the ARINC 653, this feature is called Multiple Module Scheduling.

Here, the module may refer to a set of execution information to execute a specific function in an aircraft using ARINC 653 as an operating system. Each module includes one or more partitions, and may include information such as an execution time for each partition, an execution cycle, an offset, and allocated cores. Each module is repeated every preset major time frame (MTF).

1 is a diagram showing an example of multiple module scheduling in ARINC 653. Referring to FIG. 1, module 1 is composed of partition 1 and partition 3, and units of partition 1 and partition 3 are set to be repeated every major time frame (MTF = 300000). Module 2 is composed of partition 2 and partition 3, and the unit of partition 2 and partition 3 is set to be repeated every major time frame (MTF = 400000). Module 3 is composed of partition 1, partition 2, and partition 3, and the unit of partition 1, partition 2, and partition 3 is set to repeat every major time frame (MTF = 300000).

Here, the partitions of each module are temporally and spatially separated. Here, that each partition is temporally separated means that the execution time of each partition is guaranteed, and each partition is independent of other partitions and interference with each other is minimized. For example, in module 1, partition 1 may have a guaranteed execution time for 20000 time frames, and partition 3 may mean that an execution time is guaranteed for 10000 time frames after the execution time of partition 1.

The fact that each partition is spatially separated means that resources allocated to each partition are guaranteed, and resources allocated to one partition may not be allocated to other partitions. Due to the characteristics of such temporal and spatial separation, safety and reliability can be guaranteed in the ARINC 653-based operating system.

And, in the ARINC 653-based operating system, one or more modules (eg, module 1 to module 3) are recorded in the configuration table in advance to ensure safety and reliability, and then the operation of the operating system is performed, and the configuration table It is impossible to change other scheduling other than the schedule recorded in advance.

In other words, in an aircraft with ARINC 653 as its operating system, if a software error occurs during operation, it can lead to very dangerous situations such as sudden engine stop or inability to control aircraft wings. It guarantees the execution of the specified operation at the specified time and uses static scheduling.

Meanwhile, the vehicle uses a standardized platform established by AUTOSAR (AUTomotive Open System ARchitecture) (an open automotive standard software architecture development partnership). AUTOSAR provides a set of specifications that describe the underlying software, define application interfaces, and establish a common development methodology based on a standardized exchange format.

Here, most of the operating systems that implement and use the AUTOSAR specification are based on operating systems for PCs (e.g. Linux), which have general security mechanisms for users, but require accuracy for performance. It is different from the separate kernel in that it compromises to some extent on reliability and stability.

In addition, in AUTOSAR, the execution manager (EM) manages the startup and shutdown of applications, and there is a big difference between the management of execution units (partitions or processes) between the aviation standard and the automotive standard. As discussed above, ARINC 653 statically manages partition execution, whereas AUTOSAR's Execution Manager (EM) dynamically manages process execution. That is, in the case of a vehicle, the number of execution units for managing various detailed functions is much greater than that of an aircraft, and the program schedule is dynamically changed depending on the situation, which is different from the execution unit management of the aviation standard.

Here, if ARINC 653 is used as a vehicle operating system, safety and reliability, which are the advantages of ARINC 653, can be obtained. However, while execution unit management of ARINC 653 is performed statically, execution unit management is performed dynamically in AUTOSAR. Therefore, in order to apply ARINC 653 as a vehicle operating system, a method for dynamically managing execution unit is required.

An object of the present invention is to provide a vehicle operating system system that can apply ARINC 653 as a vehicle operating system and a vehicle having the same.

On the other hand, the technical problems to be achieved in the present invention are not limited to the above-mentioned technical problems, and other technical problems that are not mentioned will become clear to those skilled in the art from the description below. You will be able to understand.

An operating system system for a vehicle according to an embodiment disclosed herein includes an operating system based on Avionics Application Standard Software Interface (ARINC) 653 mounted on a vehicle; An AUTOSAR (AUTomotive Open System ARchitecture) platform that is a software architecture mounted on the vehicle and includes an execution manager that generates a first type execution management schedule; and a conversion interface for combining the ARINC 653-based operating system and the AUTOSAR platform and converting the first-type execution management schedule into a second-type execution management schedule usable in the ARINC 653-based operating system. include

The execution manager, when a preset situation event occurs in the vehicle, selects processes to be executed in response to the situation, and designates a start and end order of each process in consideration of dependencies between the selected processes, so that the first process You can create an execution management schedule of the form.

The conversion interface may convert an execution management schedule of the first type into an execution management schedule of the second type based on dependencies between processes and an execution time of each process in the execution management schedule of the first type.

The conversion interface generates a plurality of modules based on the dependencies between processes and the execution time of each process, the execution management schedule of the second type includes the plurality of modules, and the modules include the first type. An execution order among processes included in the execution management schedule of the , an execution time of each process, and a repetition cycle of the corresponding module may be included.

The inter-process dependency includes a running dependency, and the conversion interface is determined when the first process has the running dependency relationship with the second process in the execution management schedule of the first type. In response to the execution start command of the second process on the execution management schedule of, a first module including only the second process is created, and in response to the execution start command of the first process on the execution management schedule of the first type A second module including the second process and the first process is generated, the first module is allocated an execution time of the second process, and the second module includes the second process and the first module. An execution order between one process and an execution time of each of the second process and the first process are allocated.

The inter-process dependencies include terminated dependencies, and the conversion interface is determined when the first process has the terminated dependency relationship with the second process in the execution management schedule of the first type. In response to an execution start command of the second process on the execution management schedule of, a first module including only the second process is created, and in response to an end wait command of the second process on the execution management schedule of the first type Maintains the first module, and generates a second module including only the first process in response to an execution start command of the first process on the execution management schedule of the first type, wherein the first module: Execution time of two processes may be allocated, and the second module may be allocated execution time of the first process.

The vehicle operating system system may further include a verification unit that verifies the execution management schedule of the second type converted by the conversion interface.

The verification unit calculates a hash value for each module included in the execution management schedule of the second type, compares the calculated hash value with a pre-stored hash value, and overwrites the verification process of the execution management schedule of the second type. heads can be minimized.

The pre-stored hash value is a hash value of a module included in the previously verified execution management schedule of the second type, and the verification unit determines whether there is a hash value identical to the calculated hash value among the pre-stored hash values. Verification can be performed according to

According to an embodiment of the present invention, by converting a dynamic execution management schedule (execution management schedule for a dependency-based process) generated in the AUTOSAR platform into a module-type execution management schedule executable in an ARINC 653-based operating system, the vehicle In addition, by applying the ARINC 653-based operating system, it is possible to perform dynamic execution management according to situational events that occur frequently in the vehicle while ensuring safety and reliability accordingly.

On the other hand, the effects obtainable in the present invention are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below. You will be able to.

1 is a diagram showing an example of multiple module scheduling in ARINC 653;

2 is a block diagram showing an ARINC 653-based vehicle operating system system according to an embodiment of the present invention;

3 is a diagram showing the state of a function group in one embodiment of the present invention;

4 is a diagram for explaining dependencies between processes in an execution management schedule generated by an execution manager according to an embodiment of the present invention;

5 is a diagram schematically showing a state in which a first type of execution management schedule is converted into a second type of execution management schedule in an embodiment of the present invention;

6 and 7 are views illustrating a process of converting a first type of execution management schedule into a second type of execution management schedule according to inter-process dependencies according to an embodiment of the present invention;

8 is a block diagram illustrating and illustrating a computing environment including a computing device suitable for use in example embodiments.

Hereinafter, embodiments of the present invention will be described in more detail with reference to the accompanying drawings. Embodiments of the present invention may be modified in various forms, and the scope of the present invention should not be construed as being limited to the following examples. This embodiment is provided to more completely explain the present invention to those skilled in the art. Accordingly, the shapes of elements in the figures are exaggerated to emphasize clearer description.

The composition of the present invention for clarifying the solution to the problem to be solved by the present invention will be described in detail with reference to the accompanying drawings based on a preferred embodiment of the present invention, but the same reference numerals are assigned to the components of the drawings. For components, even if they are on other drawings, the same reference numerals have been given, and it is made clear in advance that components of other drawings can be cited if necessary in the description of the drawings.

2 is a block diagram illustrating an ARINC 653-based vehicle operating system system according to an embodiment of the present invention.

Referring to FIG. 2 , the vehicle operating system system 100 includes an AUTOSAR platform 102 , a conversion interface 104 , and an ARINC 653-based operating system 106 .

The AUTOSAR platform 102 is a standardized software architecture mounted on vehicles. The AUTOSAR platform 102 may be an adaptive platform, but is not limited thereto and may be a classic platform.

The AUTOSAR platform 102 includes an Execution Manager (EM) 102a. In addition, since the structure of the AUTOSAR platform 102 is a known technology, a detailed description thereof will be omitted.

The execution manager 102a may manage processes to be executed in each preset situation of a vehicle equipped with the vehicle OS system 100 . At this time, the execution manager 102a manages a plurality of function groups.

Here, the function group may mean a set of processes (ie, partitions) related to a specific function of the vehicle.

A process or partition is an execution unit related to a specific function, and may be used with the same meaning in this specification. To elaborate, in AUTOSAR, an execution unit is referred to as a process, and in ARINC 653, an execution unit is referred to as a partition. In this specification, the two may be used interchangeably (ie, execution unit).

For example, functional group A (FG_A) may be a set of processes managing motors, functional group B (FG_B) may be a set of processes managing navigation, and function group C (FG_C) may be managing brakes. It may be a set of processes that

And, each functional group can have several states. As shown in FIG. 3 , a functional group A (FG_A), which is a set of processes managing motors, may have states such as startup and off. In addition, functional group B (FG_B), which is a set of processes managing navigation, may have states such as inactivation, execution, and update. Also, for each function group, processes to be executed in each state are preset.

Referring to FIG. 3 , functional group A (FG_A) may be configured to execute processes P2, P3, and P4 in a startup state and process P1 to be executed in an off state.

When a preset situation event occurs in the vehicle, the execution manager 102a selects processes to be executed in response to the situation and designates the start and end order of each process in consideration of dependencies between the selected processes, thereby managing an execution management schedule. can create

That is, the execution manager 102a of the AUTOSAR platform 102 may dynamically create an execution management schedule for each preset situation event of the vehicle. In this case, one or more functional groups may be included in the execution management schedule, and each functional group may have a specific state at a specific time.

In this execution management schedule, the execution condition of each process depends on dependencies between processes.

Here, there are two types of dependencies between processes: Running and Terminated. Running dependency may mean that a corresponding process is executed after the process on which the corresponding process depends is executed.

Terminated dependencies may mean that a corresponding process is executed after the process on which the corresponding process depends is terminated. Information about dependencies between processes is stored in the Application Manifest file.

4 is a diagram for explaining dependencies between processes in an execution management schedule generated by an execution manager 102a according to an embodiment of the present invention.

4, looking at the Startup state of functional group A (FG_A), process 4 (P4) has an execution dependency relationship with process 2 (P2), and process 2 (P2) has a termination dependency relationship with process 3 (P3). there is. In this case, process 4 (P4) may be executed after process 2 (P2) is executed. Also, process 2 (P2) may be executed after process 3 (P3) is terminated.

The conversion interface 104 may serve as an interface between the AUTOSAR platform 102 and the ARINC 653-based operating system 106.

The conversion interface 104 may receive an execution management schedule created by the execution manager 102a from the execution manager 102a, convert it into a module-type execution management schedule, and transmit it to the ARINC 653-based operating system 106. .

That is, since the execution management schedule created by the execution manager 102a is created in the AUTOSAR platform 102 and is dependency-based process execution management, it is a module-type execution management that can be used in the ARINC 653-based operating system 106. Convert to schedule.

Hereinafter, the execution management schedule generated by the execution manager 102a may be referred to as a first type execution management schedule. In addition, the module type execution management schedule may be referred to as a second type execution management schedule.

Accordingly, the conversion interface 104 may convert the execution management schedule of the first type into the execution management schedule of the second type, and then transfer the conversion to the ARINC 653-based operating system 106 . Accordingly, it is possible to dynamically update the execution management schedule even while the vehicle OS system 100 is running.

The conversion interface 104 may convert the execution management schedule of the first type into the execution management schedule of the second type based on the dependency between processes and the execution time of each process in the execution management schedule of the first type.

5 is a diagram schematically illustrating a state in which a first type of execution management schedule is converted into a second type of execution management schedule in an embodiment of the present invention.

Here, a module is a set of execution information for executing a specific function in the ARINC 653-based operating system 106, and may include one or more partitions.

In addition, the module may include an execution order among processes included in the execution management schedule of the first type, an execution time of each process, and a repetition cycle of the corresponding module.

6 and 7 are diagrams illustrating a process of converting a first type of execution management schedule into a second type of execution management schedule according to dependencies between processes according to an embodiment of the present invention.

Referring to FIG. 6 , it is assumed that process 3 (P3) of functional group A (FG_A) has an execution dependency relationship with process 1 (P1) in the first type of execution management schedule. In this case, the conversion interface 104 may generate the first module M1 in response to the execution start command (start(P1)) of the process 1 (P1) on the execution management schedule of the first form.

The first module M1 may include only process 1 (P1) (ie, partition 1) of functional group A (FG_A), and the execution time for process 1 (P1) may be allocated.

Next, the conversion interface 104 may generate the second module M2 in response to the execution start command (start(P3)) of the process 3 (P3) on the first type of execution management schedule.

The second module M2 includes process 1 (P1) (ie, partition 1) and process 3 (P3) (ie, partition 3) of functional group A (FG_A), and process 1 (P1) and process 3 ( The execution order of P3) and the execution time of each process may be allocated. At this time, the conversion interface 104 may divide and allocate the total execution time of the process 1 (P1) to the first module (M1) and the second module (M2).

In this way, the conversion interface 104 may convert the first type of execution management schedule into a second type of execution management schedule including the first module M1 and the second module M2.

When the second type of execution management schedule is executed in the ARINC 653-based operating system 106, the first module M1 is executed and then changed to the second module M2 to be executed. At this time, when the first module (M1) is executed, only process 1 (P1) of functional group A (FG_A) is executed, and when the module is changed to the second module (M2), process 1 (P1) of functional group A (FG_A) and process 3 (P3) are repeated and executed.

Referring to FIG. 7 , it is assumed that process 3 (P3) of functional group B (FG_B) has a termination dependency relationship with process 2 (P2) in the first type of execution management schedule.

In this case, the conversion interface 104 generates the first module M1 in response to the execution start command (start(P2)) of the process 2 (P2) of the functional group B (FG_B) on the execution management schedule of the first form. can do.

The first module (M1) may include only process 2 (P2) of functional group B (FG_B), and execution time for process 2 (P2) may be allocated.

Next, the conversion interface 104 maintains the first module M1 in response to the process 2 (P2) end wait command (wait(P2)) of the functional group B (FG_B). That is, the conversion interface 104 may maintain the first module M1 without changing the module until the execution of the process 2 (P2) ends.

Next, the conversion interface 104 may generate the second module M2 in response to the execution start command (start(P3)) of the process 3 (P3) of the functional group B (FG_B).

The second module M2 may include only the process 3 (P3) of the functional group B (FG_B), and the execution time for the process 3 (P3) may be allocated.

Meanwhile, when the second type of execution management schedule is executed in the ARINC 653-based operating system 106, when the first module (M1) is executed and the process 2 (P2) of the functional group B (FG_B) is terminated, the second The module is changed to module M2 and executed.

Referring back to FIG. 2 , the ARINC 653-based operating system 106 can control each hardware installed in a vehicle, provide a base environment for application software, and manage computing resources in the vehicle.

The ARINC 653-based operating system 106 may receive the second type of execution management schedule from the conversion interface 104 . The ARINC 653-based operating system 106 may include a verification unit 106a for verifying the execution management schedule of the second type.

That is, since the second type of execution management schedule received from the conversion interface 104 is a dynamic execution management schedule generated from the execution manager 102a, if it is immediately executed, the safety and stability of the ARINC 653-based operating system 106 Reliability can be difficult to ensure. In the embodiment disclosed herein, the execution management schedule of the second type received from the conversion interface 104 may be verified through the verification unit 106a.

Specifically, the verification unit 106a may calculate a hash value for each module included in the execution management schedule of the second form.

That is, the verification unit 106a may calculate a hash value by inputting each module included in the execution management schedule of the second type to a hash function.

The verification unit 106a may compare the calculated hash value with pre-stored hash values. Here, the pre-stored hash values may be hash values of modules included in the previously verified execution management schedule of the second type.

The verification unit 106a may verify the received execution management schedule of the second type through whether there is a hash value identical to the calculated hash value among pre-stored hash values.

If there is no hash value identical to the calculated hash value among pre-stored hash values, the verification unit 106a may determine that the received execution management schedule of the second type has not yet been verified. At this time, the verification unit 106a verifies the stability and reliability of the execution management schedule of the second type, and stores the hash value when the verification is completed. Thereafter, in the case of the second type of execution management schedule in which the stored hash value is calculated, verification may be regarded as complete even without additional verification.

That is, if there is a hash value identical to the calculated hash value among pre-stored hash values, the verification unit 106a may determine that the received execution management schedule of the second type has already been verified. In this case, the ARINC 653-based operating system 106 can execute the execution management schedule of the second type by adding it to the configuration table.

According to the disclosed embodiment, since additional verification is not performed on the previously verified execution management schedule of the second type, it is not necessary to undergo full-scale verification each time the execution management schedule of the second type is generated. As a result, according to the disclosed embodiment, in the process of converting the execution management schedule of the first type into the execution management schedule of the second type, the conversion speed can be improved by reducing the time required for verification.

According to the disclosed embodiment, the dynamic execution management schedule (execution management schedule for a dependency-based process) generated in the AUATSAR platform 102 is converted into a module-type execution management schedule executable in the ARINC 653-based operating system 106. By converting, it is possible to apply the ARINC 653-based operating system 106 to the vehicle to secure safety and reliability and perform dynamic execution management according to situational events that frequently occur in the vehicle.

8 is a block diagram illustrating and describing a computing environment 10 including a computing device suitable for use in example embodiments.

In the illustrated embodiment, each component may have different functions and capabilities other than those described below, and may include additional components other than those described below.

The illustrated computing environment 10 includes a computing device 12 . In one embodiment, computing device 12 may be vehicle operating system system 100 .

Computing device 12 includes at least one processor 14 , a computer readable storage medium 16 and a communication bus 18 . Processor 14 may cause computing device 12 to operate according to the above-mentioned example embodiments. For example, processor 14 may execute one or more programs stored on computer readable storage medium 16 . The one or more programs may include one or more computer-executable instructions, which when executed by processor 14 are configured to cause computing device 12 to perform operations in accordance with an illustrative embodiment. It can be.

Computer-readable storage medium 16 is configured to store computer-executable instructions or program code, program data, and/or other suitable form of information. Program 20 stored on computer readable storage medium 16 includes a set of instructions executable by processor 14 . In one embodiment, computer readable storage medium 16 includes memory (volatile memory such as random access memory, non-volatile memory, or a suitable combination thereof), one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, other forms of storage media that can be accessed by computing device 12 and store desired information, or any suitable combination thereof.

Communications bus 18 interconnects various other components of computing device 12, including processor 14 and computer-readable storage medium 16.

Computing device 12 may also include one or more input/output interfaces 22 and one or more network communication interfaces 26 that provide interfaces for one or more input/output devices 24 . An input/output interface 22 and a network communication interface 26 are connected to the communication bus 18 . Input/output device 24 may be coupled to other components of computing device 12 via input/output interface 22 . Exemplary input/output devices 24 include a pointing device (such as a mouse or trackpad), a keyboard, a touch input device (such as a touchpad or touchscreen), a voice or sound input device, various types of sensor devices, and/or a photographing device. input devices, and/or output devices such as display devices, printers, speakers, and/or network cards. The exemplary input/output device 24 may be included inside the computing device 12 as a component constituting the computing device 12, or may be connected to the computing device 12 as a separate device distinct from the computing device 12. may be

The above detailed description is illustrative of the present invention. In addition, the foregoing is intended to illustrate and describe preferred embodiments of the present invention, and the present invention can be used in various other combinations, modifications, and environments. That is, changes or modifications are possible within the scope of the concept of the invention disclosed in this specification, within the scope equivalent to the written disclosure and / or within the scope of skill or knowledge in the art. The written embodiment describes the best state for implementing the technical idea of the present invention, and various changes required in the specific application field and use of the present invention are also possible. Therefore, the above detailed description of the invention is not intended to limit the invention to the disclosed embodiments. Also, the appended claims should be construed to cover other embodiments as well.

Claims

ARINC (Avionics Application Standard Software Interface) 653-based operating system mounted on vehicles;

An AUTOSAR (AUTomotive Open System ARchitecture) platform that is a software architecture mounted on the vehicle and includes an execution manager that generates a first type execution management schedule; and

Includes a conversion interface that interfaces between the ARINC 653-based operating system and the AUTOSAR platform and converts the first-type execution management schedule into a second-type execution management schedule usable in the ARINC 653-based operating system , an operating system system for vehicles.
The method of claim 1,

The execution manager,

When a predetermined situation event occurs in the vehicle, processes to be executed in response to the situation are selected, and the start and end order of each process is designated in consideration of dependencies between the selected processes, thereby managing the first type of execution management schedule. , operating system system for vehicles.
The method of claim 2,

The conversion interface is

A vehicle operating system system that converts an execution management schedule of the first type into an execution management schedule of the second type based on dependencies between processes and an execution time of each process in the execution management schedule of the first type.
The method of claim 3,

The conversion interface is

A plurality of modules are generated based on the dependencies between the processes and the execution time of each process, and the execution management schedule of the second type includes the plurality of modules;

The module includes an execution order among processes included in the execution management schedule of the first form, an execution time of each process, and a repetition period of the corresponding module.
The method of claim 4,

The inter-process dependency includes a running dependency,

The conversion interface is

In the execution management schedule of the first form, when the first process is in the execution dependency relationship with the second process,

Creating a first module including only the second process in response to an execution start command of the second process on the first type of execution management schedule;

Creating a second module including the second process and the first process in response to an execution start command of the first process on the execution management schedule of the first form;

The first module is assigned the execution time of the second process,

In the second module, an execution order between the second process and the first process and an execution time of the second process and the first process are allocated,

The vehicle operating system system of claim 1 , wherein the total execution time of the second process is divided and allocated to the first module and the second module.
The method of claim 4,

The inter-process dependencies include terminated dependencies,

The conversion interface is

In the execution management schedule of the first form, when the first process is in the termination dependency relationship with the second process,

Creating a first module including only the second process in response to an execution start command of the second process on the first type of execution management schedule;

Maintaining the first module in response to an end wait command of the second process on the execution management schedule of the first form;

Creating a second module including only the first process in response to an execution start command of the first process on the execution management schedule of the first form;

The first module is assigned the execution time of the second process,

The second module is one to which the execution time of the first process is allocated.
The method of claim 1,

The vehicle operating system system,

and a verification unit that verifies the execution management schedule of the second type converted by the conversion interface.
The method of claim 7,

The verification unit,

A vehicle operating system system that calculates a hash value for each module included in the second type of execution management schedule and compares the calculated hash value with a pre-stored hash value to verify the second type of execution management schedule.
The method of claim 8,

The pre-stored hash value is a hash value of a module included in the previously verified execution management schedule of the second type,

The verification unit,

The vehicle operating system system that performs verification according to whether there is a hash value identical to the calculated hash value among the pre-stored hash values.
A vehicle having the vehicle operating system system according to claim 1 .