KR102349107B1 - Method for managing execution of runnables on autosar platform - Google Patents

Abstract

A method is provided for managing runnable execution on the Ottosa platform. Embodiments of the present invention define a precedence relationship of execution of a plurality of runnables in advance, and when a first runnable among a plurality of runnables is called, based on an event chain record, the first runnable is higher than the first runnable. First, it is checked whether the runables to be executed are normally executed, and if they are normally executed, the first runable is executed, and the completion of the first runable execution is recorded in the event chain. By sharing an event chain among a plurality of processors and/or cores, it is possible to manage the execution precedence relationship between runners and applications running on different processors and/or cores.

Description

METHOD FOR MANAGING EXECUTION OF RUNNABLES ON AUTOSAR PLATFORM

The present invention relates to a method for managing application runnable execution on the Ottosa platform. More specifically, it relates to a method for managing application runners to be executed according to a predetermined execution order on the Otosa platform, and performing appropriate error handling when they are executed in an abnormal order.

A conventional automobile is a set of mechanical devices, but more and more electronic devices are being installed in recent automobiles, and it is no exaggeration to say that the automobile is a collection of various electronic devices. As functions such as vehicle posture control, automatic parking, intelligent driving assistance and autonomous driving become more common, more and more electronic devices are interlocking with each other in automobiles.

As the number of electronic devices used in automobiles increases, the demand for standardization of software used therein also increases. Accordingly, an Embedded Software Open Platform called AUTOSAR, which was developed to increase module reusability and improve compatibility of parts for each vehicle, is widely used.

AUTOSAR (AUTomotive Open System ARchitecture) is an open automotive standard software architecture. Auto Corporation is the name of an organization and standardization standard launched by automobile manufacturers, parts suppliers, and IT technology companies to standardize electronic devices used in automobiles. For more information on this, visit Autosar's website (http://www.autosar.org/).

Otosa OS is an operating system that supports preemptive multi-tasking and provides a standardized interface to applications. Through a standardized interface, hardware-independent application development is possible, and scalability and stability can be improved. In addition, through scheduling, multiple tasks can be distributed and performed in one ECU, maximizing the utilization of hardware resources.

The application software in the Ottosa platform is modularized and designed in units of software components, and the functions of the software components are implemented through code units called runnables. In the Otosa platform, a task is a unit of job scheduling for the OS to allocate resources to execute software. Application software is executed as a runnable unit mapped to a task.

In one ECU, several tasks that execute different runables exist, the state of the task changes depending on the situation, and the task is called and the work is performed.

Otto has a Watchdog Manager to ensure that tasks are executed in the proper order. The watchdog manager monitors the operation of the application task in accordance with the monitoring conditions by monitoring it. The monitoring conditions of the watchdog manager are Alive Supervision, Deadline Supervision, Logical Supervision, etc. Logical Supervision defines the order between the monitoring points of the monitoring target and monitors the execution order. When the watchdog manager detects an error in the function, execution time, and sequence of the task being executed, it transmits a triggering condition to the hardware watchdog and resets the hardware to initialize the system.

However, the watchdog-based task execution order management function provided by Autosa does not support multi-processors and multi-cores, and there is a limitation in that checkpoints can be configured only between tasks executed in the same core. There is a significant limitation in that only an operation for resetting the hardware is provided. Therefore, it is necessary to manage the execution order between tasks executed in different processors or cores and provide an appropriate error handling option.

Korean Patent Publication No. 10-1794568 (2017.11.01.)

The technical problem to be solved by the present invention is to provide a method for managing the execution order of application runners in the Ottosa platform.

Another technical problem to be solved by the present invention is to provide a method of managing the execution order of runners between different control units in an Ottosa platform that is executed by a plurality of control units such as multi-processors or multi-cores.

Another technical problem to be solved by the present invention is to provide a method for managing the execution order of application runners without modification of application software running on the Ottosa platform.

Another technical problem to be solved by the present invention is to provide a method for handling an error in an appropriate manner when the execution order of application runners is not observed in the Otosa platform.

The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the following description.

In order to solve the above-described technical problem, a method for managing runnable execution in an Ottosa platform according to an embodiment of the present invention includes: acquiring prerequisites for execution of a plurality of runnables; Performing pre-processing for determining whether a prerequisite for execution of a first of the runners is satisfied; executing the first runner; may include performing post-processing of adding to the event chain.

In an embodiment, the prerequisites for the execution of the plurality of runners may indicate a precedence relationship of the execution of the plurality of runners.

In an embodiment, the prerequisites for execution of the plurality of runners may include information about one or more other runners to be executed before the first runnerable.

In an embodiment, the prerequisites for execution of the plurality of runners are defined in advance using the event identifier, wherein the event identifier is an identifier unique to the plurality of runners and an identifier indicating execution start or execution completion. may include.

In an embodiment, the performing of the pre-processing may further include adding an event identifier indicating the fact that the first runnable execution is started to the event chain.

In one embodiment, determining whether a prerequisite of execution of the first runnable is satisfied comprises: identifying, from the prerequisites, identifiers of antecedent events to be completed before the first runnable; and searching for identifiers of the preceding events in the event chain, wherein executing the first runnable comprises: based on a determination that a prerequisite of executing the first runnable is satisfied, the first runnable It may include the step of executing

In one embodiment, the event chain may be recorded in an ordered list.

In one embodiment, the performing the pre-processing and the performing the post-processing are performed by a middleware, and the performing the pre-processing includes: detecting, by the middleware, the first runnable execution call; and reading, by the middleware, the event chain, wherein the performing the post-processing includes: detecting, by the middleware, completion of execution of the first runnable; It may include adding an event identifier indicating the fact of completion of the to the event chain.

In an embodiment, the plurality of runners may include a runner that is executed in a first control unit and a runner that is executed in a second control unit that is distinct from the first control unit.

In an embodiment, the first runnable is executed in a first control unit, and the performing the post-processing further comprises: the first control unit sending the event chain to the second control unit can do.

In an embodiment, the first runable may be executed in a first control unit, and may further include the step of merging, by the first control unit, an event identifier received from the second control unit into the event chain.

In an embodiment, the event identifier may further include an identifier that distinguishes a plurality of control units including the first control unit and the second control unit from each other.

In one embodiment, the method may further include executing a predefined error handling routine based on a determination that the prerequisite of the first runnable execution is not met.

In an embodiment, the predefined error handling routine may be defined differently for different runables.

In an embodiment, the predefined error handling routine may be defined differently for different prerequisites.

A storage medium in which a program is recorded according to another embodiment of the present invention for solving the above-described technical problem is a storage medium in which a runable execution management program in an Ottosa platform is recorded, and the program is an instruction for obtaining prerequisites for execution, an instruction for performing preprocessing for determining whether a prerequisite for execution of a first runner from among the plurality of runables is satisfied; an instruction for executing the first runner; and an instruction for performing post-processing of adding an event identifier indicating the completion of the first runnable execution to the event chain.

According to the above-described embodiments of the present invention, it is possible to manage the execution order of runners among different control units in the Ottosa platform executed by a plurality of control units such as multi-processors or multi-cores.

In addition, according to the above-described embodiments of the present invention, it is possible to manage the execution order of application runners without modification of application software executed on the Ottosa platform.

In addition, according to the above-described embodiments of the present invention, when the execution order of the application runners is not observed in the Autosa platform, in addition to the hardware reset, the error log is recorded, the notification of the occurrence of an error, and the error is ignored and the runner It becomes possible to handle errors in an appropriate way according to various error occurrence situations such as execution of a block.

Effects of the present invention are not limited to the above-mentioned effects, and other effects not mentioned will be clearly understood by those skilled in the art from the following description.

1 is a configuration diagram for explaining the Ottosa platform used in an embodiment of the present invention.
FIG. 2 is a reference diagram illustrating an exemplary execution order or a precedence relationship of execution of application runners in the Ottosa platform.
3 is a flowchart of a method for managing application runner execution in the Ottosa platform, according to an embodiment of the present invention.
4 is a reference diagram for explaining an exemplary bit structure of an identifier for recording events including the initiation and completion of runnable execution in some embodiments of the present invention.
5 is a reference diagram for explaining an exemplary data structure expressing prerequisites for initiation of each runnable execution in some embodiments of the present invention.
6 is a reference diagram for explaining an exemplary data structure of an event chain in which events including the initiation and completion of a runnable execution are recorded in some embodiments of the present invention.
FIG. 7 is a diagram for describing in more detail some steps of the method for managing a runable execution described with reference to FIG. 3 .
FIG. 8 is a diagram for explaining in more detail some steps of the method for managing a runnable execution described with reference to FIG. 3 .
9 is a reference diagram for explaining a process in which an execution order among application runners executed in two or more control units is managed in some embodiments of the present invention.
10 is a reference diagram for explaining an example in which the method for managing runable execution according to an embodiment of the present invention is applied to a driving assistance system.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. Advantages and features of the present invention and methods of achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the technical spirit of the present invention is not limited to the following embodiments, but may be implemented in various different forms, and only the following embodiments complete the technical spirit of the present invention, and in the technical field to which the present invention belongs It is provided to fully inform those of ordinary skill in the art of the scope of the present invention, and the technical spirit of the present invention is only defined by the scope of the claims.

In adding reference numerals to the components of each drawing, it should be noted that the same components are given the same reference numerals as much as possible even though they are indicated on different drawings. In addition, in describing the present invention, if it is determined that a detailed description of a related known configuration or function may obscure the gist of the present invention, the detailed description thereof will be omitted.

Unless otherwise defined, all terms (including technical and scientific terms) used herein may be used with the meaning commonly understood by those of ordinary skill in the art to which the present invention belongs. In addition, terms defined in a commonly used dictionary are not to be interpreted ideally or excessively unless clearly defined in particular. The terminology used herein is for the purpose of describing the embodiments and is not intended to limit the present invention. In this specification, the singular also includes the plural unless specifically stated otherwise in the phrase.

In addition, in describing the components of the present invention, terms such as first, second, A, B, (a), (b), etc. may be used. These terms are only for distinguishing the elements from other elements, and the essence, order, or order of the elements are not limited by the terms. When it is described that a component is “connected”, “coupled” or “connected” to another component, the component may be directly connected or connected to the other component, but another component is formed between each component. It should be understood that elements may also be “connected,” “coupled,” or “connected.”

As used herein, "comprises" and/or "comprising" refers to the presence of one or more other components, steps, operations and/or elements mentioned. or addition is not excluded.

In this specification, an Electronic Control Unit (ECU), a Micro Controller Unit (MCU), a Central Processing Unit (CPU), a processor, and a plurality of cores in the processor refer to a configuration that processes and/or calculates data. common, and may be collectively referred to as a 'control unit' in this specification.

Hereinafter, some embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a configuration diagram for explaining the Ottosa platform used in an embodiment of the present invention.

Referring to FIG. 1 , Otto's software is largely composed of three layers: SWC (Software Component; 107), RTE (Run Time Environment; 105), and BSW (Basic Software; 103). In Otto's standard platform, several components have input/output ports and communicate with each other virtually through Component-Based Software Development (CBD).

SWC 107 is located at the highest level and performs engine, automatic transmission, and brake control functions, and is placed in a virtual network called VFB (Virtual Functional Bus) and interlocked with ECU. The RTE 105 is located between the SWC 107 and the BSW 103, and provides an interface for data exchange therebetween. The RTE 105 may be understood as a kind of middleware in that the SWC 107 performs a communication connection between modules to provide independence that is not dependent on hardware. The BSW 103 is located in the lowest layer and provides services for performing tasks necessary for the SWC 107 such as an operating system (OS), a device driver, and communication.

FIG. 2 is a conceptual diagram illustrating a method for managing an application runnable execution in the Ottosa platform according to an embodiment of the present invention. Specifically, FIG. 2 shows an exemplary execution sequence of a plurality of runners that are distributed and executed on a total of three cores (CORE #0, CORE #1, CORE #2) in a single processor.

In the exemplary execution sequence shown in FIG. 2 , runable #000 (201) and runable #001 (202) are executed in CORE #0, runable #010 (203), runable #011 (204), and Runables #012 (205) are executed in CORE #1, and Runables #020 (206) and Runables #021 (207) are executed in CORE #2.

In FIG. 2 , the runners shown on the relatively left are runners to be executed earlier, and the runners shown on the relatively right are runners that should be executed later. For example, runable #000 (201) is defined to be executed earlier than runable #001 (202), and runable #021 (207) is defined to be executed later than runable #020 (206).

In the exemplary execution sequence shown in FIG. 2 , bold arrows 211 to 216 indicate precedence relationships between executions of runnables. That is, it can be understood that the bold arrows 211 to 216 inserted to the left side of each runable indicate a preceding runner that is to be executed before the corresponding runner. For example, arrow 211 indicates that runable #000(201) should be executed before runable #010(203), and the completion of execution of runable #000(201) results in execution of runable #010(203). It is a prerequisite to be met before initiation.

In Figure 2, runable #000 (201), runable #020 (206), and runable #021 (207) have no prerequisites, whereas runable #010 (203) running on CORE #1 is , execution can be started only after the execution of the runable #000 (201) is completed in CORE #0 and the execution of the runable #020 (206) is completed in CORE #2. Similarly, for runable #011 (204) executed in CORE #1, execution of runable #010 (203) is completed in CORE #1, and execution of runable #021 (207) is completed in CORE #2 Execution can be started only afterward, and runable #001 (202) executed in CORE #0 can be started only after execution of runable #011 (204) in CORE #1 is completed.

As exemplarily illustrated in FIG. 2 , an execution order or precedence relation of execution may exist between a plurality of runables. Also, the plurality of runners may be executed in different processors or distributedly executed in different cores of the same processor. Accordingly, there is a need to provide a method for managing the execution order between runables as exemplarily shown in FIG. 2 . Hereinafter, a runner execution management method according to an embodiment of the present invention will be described with reference to FIGS. 3 to 8 .

3 is a flowchart of a method for managing the execution of application runners in the Ottosa platform, according to an embodiment of the present invention. However, this is only a preferred embodiment for achieving the object of the present invention, and some steps may be added or deleted as necessary.

Each step of the method for managing runner execution shown in FIG. 3 is provided with a single processor having a single core, a single processor having a plurality of cores, or a plurality of processors having a single or multiple cores, and is installed on the Ottosa platform. The application may be executed by the implemented computing device. In other words, each step of the method for managing runnable execution may be implemented with one or more instructions executed by a processor of a computing device. All of the steps included in the method for managing runnable execution may be executed by one physical computing device, but the first steps of the method are performed by a first computing device, and the second steps of the method are performed by a second It may be performed by a computing device. Hereinafter, it is assumed that each step of the method for managing runable execution is performed by one computing device or one control unit in one computing device. However, for convenience of description, the description of the operating subject of each step included in the runnerable execution management method may be omitted.

Referring to FIG. 3 , the method for managing runner execution according to the present embodiment includes the steps of: obtaining execution prerequisites of a plurality of runners ( S100 ), and determining whether the prerequisites of the first runnerable execution are satisfied ( S200 ) ), when the preceding condition is satisfied (S300), executing the first runable (S400) and recording the completion of the first runnable execution (S500), when the preceding condition is not satisfied (S300), performing an error handling routine (S600) may be included. Hereinafter, it will be described in detail. Steps S200, 300, 500, and S600 may be implemented as a part of the middleware layer between the BSW layer and the SWC layer, and may be performed by the middleware.

In step S100 , prerequisite conditions to be satisfied before each of the plurality of runables are executed are obtained.

As described above with reference to FIG. 2 , an execution order or an execution precedence relationship may exist between a plurality of runables. The execution order between runnables may be defined and recorded in advance by a person who designs an application or configures a system using various applications, and may be referenced at runtime. Hereinafter, with reference to FIGS. 4 and 5 , in some embodiments of the present invention, a detailed manner in which an execution order of runnables is defined will be described in more detail.

In some embodiments of the present invention, the order of execution between the runnables may be defined by describing the precedence relationship between the execution start and execution completion events of each runnable. Execution initiation and execution completion of each runnable are considered as separate events, respectively, an identifier indicating each event is given, a precedence relationship between the events is defined through the event identifier, and the occurrence of a series of events is recorded .

4 illustrates an exemplary bit structure of an identifier for recording events including the initiation and completion of runnable execution in some embodiments of the present invention. The event identifier can be expressed with a total of 16 bits, and the first 4 bits indicate the start (1000) and completion (0000) of the runnable execution. The second 4 bits are bits for specifying a processor on which the corresponding runable is executed among the plurality of processors, and the third 4 bits are bits for specifying a core on which the corresponding runner is executed among the plurality of cores. The last 4 bits are bits for an identifier for distinguishing from each other several runables that can be executed on the same core of the same processor. Hereinafter, a total of 16-bit event identifier is expressed as a 4-digit hexadecimal number. For example, the event identifier 0012 is an identifier indicating the start of execution of runner 2 executed in core 1 of CPU 0, and 8012 is an identifier indicating completion of execution of runner 2 executed in core 1 of CPU 0 to be. Similarly, the event identifier 0001 is an identifier indicating the start of execution of runner 1 executed on core 0 of CPU 0, and 8021 indicates the completion of execution of runner 1 executed on core 2 of CPU 0 It is an identifier.

FIG. 5 is a reference diagram for explaining an exemplary data structure for expressing prerequisites for initiating execution of each runnable in some embodiments of the present invention. have.

Referring to FIG. 5 , the prerequisite 501 indicates that there is no preceding event of the execution start event of runner 0, which is executed on core 0 of CPU 0 indicated by the event identifier '0000'. Precondition 506 and precondition 507 indicate that there is no preceding event of event identifiers '0020' and '0021', respectively.

On the other hand, the prerequisite 502 is the event identifier '8011', that is, the event identifier '8011', i.e., 1 of CPU 0, the preceding event of the execution start event of the 1st runable executed on the 0th core of the 0th CPU indicated by the event identifier '0001'. Indicates that the execution of Runable No. 1 executed on Core No. 1 has been completed. In other words, according to the prerequisite 502, before the execution of runner 1 executed on core 0 of CPU 0 starts, the execution of runner 1 executed on core 1 of CPU 0 is should be completed

In addition, the prerequisite 503 is that the preceding event of the execution start event of the runner 0 executed on the 1 core of the 0 CPU indicated by the event identifier '0010' is the event identifier '8000' and ('CondLogic: AND') ) indicates '8020'. That is, after both runable 0 executed on core 0 of CPU 0 and runable 0 executed on core 2 of CPU 0 ('CondLogic: AND') are all executed, number 1 of CPU 0 It is defined that the execution of runnable 0, which is executed in the core, should be started.

In addition, the prerequisite 504 is that the preceding event of the execution start event of the first runnable executed in the first core of the zero CPU indicated by the event identifier '0011' is the event identifier '8010' and ('CondLogic: AND'). ) indicates '8021'.

As described above, the prerequisites for the execution of each runnable, specifically other runnables to be completed before the start of the execution of each runnable, are specified in advance according to the scheme shown in FIG. 5 and are to be referenced at runtime. can

With reference to FIG. 3 again, the step S100 will be described continuously. As described above, in step S100 , information including prerequisites for execution of each of the plurality of runables is obtained. The preceding condition may be defined according to the data structure and method described with reference to FIG. 5, and in this case, event identifiers having the bit structure described with reference to FIG. 4 may be used to define the preceding condition.

In step S200 , it is detected by the middleware that the execution of the first runnable is requested among the plurality of runables, and prior to the execution of the first runnable, it is determined whether the prerequisite for the execution of the first runnable is satisfied. is judged What are the prerequisites for the first runnable execution may be identified from the information obtained in step S100. Whether the prerequisites of the identified first runnable execution are satisfied, for example, whether the runnables that are to be completed before the first runnable are actually executed may be determined with reference to an event chain to be described later. Hereinafter, an event chain will be described with reference to FIG. 6 .

6 is a reference diagram for explaining an exemplary data structure of an event chain in which a history of occurrences of events including the initiation and completion of each runnable execution is recorded, in some embodiments of the present invention. As shown in FIG. 6 , event identifiers indicating the execution start and completion events of each runnable are recorded according to the occurrence order of the events, which is referred to as an event chain in this specification. The event chain may be stored, for example, in an ordered list data structure. As will be described later, at the initiation and completion of each runnable execution, event identifiers indicating the initiation and completion of the runnable execution are recorded in the event chain data structure, and can be referenced whenever necessary.

With reference to FIG. 3 again, the step S200 will be described further. Identifiers of the events that should precede the first runnable, identified from the information obtained in step S100, are searched for in the event chain described with reference to FIG. It can be determined whether In other words, it may be determined whether a prerequisite for execution of the first runnable is satisfied. The search may be performed by searching the event chain in chronological order, in reverse order, or by searching in another order or method, but the present invention is not limited thereto.

In one embodiment, in step S200 , the fact of starting the first runnable execution may be recorded in the event chain. That is, an event identifier indicating the start of the first runnable execution may be recorded in the event chain.

Step S200 may be performed in the middleware layer, and may be understood as a pre-processing step performed before the first runable is executed.

Meanwhile, in embodiments in which a plurality of runners are distributed and executed in two or more processors and/or two or more cores, the event chain recorded in step S200 may be transmitted to other processors or cores. This will be described later in more detail with reference to FIG. 7 .

In step S300 of FIG. 3 , if the prerequisite for the first runnerable execution is satisfied, the process proceeds to step S400 , and if the prerequisite for the first runnerable execution is not satisfied, the process proceeds to step S600 .

If it is determined in step S300 that the prerequisite for the execution of the first runnable is satisfied, in step S400, the middleware requests the SWC layer to execute the first loveable, and in the SWC layer, the first runnable is is executed

When the execution of the first runnable is completed, in step S500 , the middleware detects the completion of the execution of the first runnable, and the completion of the first runnable execution is recorded in the event chain. That is, an event identifier indicating the completion of the first runnable execution is recorded in the event chain. Accordingly, it is possible to determine whether the execution of the first runnable has been completed from the event chain before another runnable having the execution completion of the first runnable as a prerequisite is executed.

The above-described step S500 may be understood as a post-processing step of the execution of the first runnable in that it is performed after the first runnable is executed.

On the other hand, in embodiments in which a plurality of runables are distributed and executed in two or more processors and/or two or more cores, the event chain recorded in step S500 is transmitted to another processor or core, and is executed in another processor or core. It may be referred to in the process of determining whether the prerequisites of the runnables are satisfied.

If it is determined in the above-described step S300 that the prerequisite for the first runnable execution is not satisfied, the process may proceed to step S600 and an error handling routine may be performed. If the execution order between runnables is not respected, it may be implied that an abnormal situation has occurred. In step S600 , an appropriate predefined error handling routine may be performed, which will be described later with reference to FIG. 8 .

FIG. 7 is a diagram for explaining in more detail step S200 of the method for managing the runable execution described with reference to FIG. 3 . Specifically, FIG. 7 is a diagram for explaining some embodiments in which a plurality of runners are distributed and executed in two or more processors and/or two or more cores. In the following description, a corresponding core of the processor on which the first runner is executed is referred to as a “first control unit”, and a processor or other core different from the first control unit is referred to as a “second control unit”.

First, in step S210, the fact that the first runnable is started to be executed may be recorded in the event chain. That is, an event identifier indicating the start of the first runnable execution may be recorded in the event chain.

In step S220 , it is determined whether the plurality of runables is a multiprocessor/core environment in which two or more processors or two or more cores are distributed and executed.

If it is a multiprocessor/core environment, the event chain of the first control unit is transmitted to the second control unit in step S230 . Subsequently, in step S240 , the first control unit receives information about events occurring in the second control unit, that is, an event chain of the second control unit, and the first control unit controls the event chain of the second control unit. 1 Merge into the event chain of the control unit. That is, information about all events occurring in the first control unit and the second control unit is integrated into one event chain.

In step S250, identifiers of events that should precede the first runnable are searched for in the event chain merged in step S240, and it is determined whether the corresponding events have already occurred prior to the first runnable. can At this time, in the merged event chain, information about all events occurring in the second control unit as well as the first control unit in which the first runable is executed is recorded, so that other control units (eg, other processors or other It becomes possible to determine whether other runables that are distributed and executed in the core) have been previously executed.

Steps S220 to S240 described with reference to FIG. 7 may be similarly performed in step S500 of FIG. 3 . After the fact of completion of the first runnable execution is recorded in the event chain of the first control unit in step S500, steps S220 to S240 of FIG. 7 may be performed. It is determined whether the plurality of runners is a multiprocessor/core environment in which two or more processors or two or more cores are distributed and executed (step S220), and if it is a multiprocessor/core environment, the first control unit in which the first runner is executed may be transmitted to the second control unit (step S230). In addition, by receiving the event chain of the second control unit and merging it into the event chain of the first control unit, information about all events occurring in the first control unit and the second control unit is updated in the event chain of the first control unit, can manage

8 is a diagram for explaining in more detail the step S600 of the method for managing the runable execution. Specifically, FIG. 8 is a diagram for explaining in more detail a process in which an error handling routine is executed when it is determined that the prerequisite for the first runnable execution is not satisfied in the above-described step S300 of FIG. 3 . .

Referring to FIG. 8 , the generated error may be recorded in step S610 . Specifically, information about the first runnable for which execution is not started because a prerequisite is not met, what an unfulfilled prerequisite is (eg, what is a previously uncompleted runnable), and a current execution environment and information about parameters and the like may be recorded as part of the error information.

In step S620, at least one of various predefined error handling methods is determined. Error handling methods may be predefined according to the type of error. For example, an error handling method may be defined differently in advance depending on which runnable has failed to start execution. Also, different error handling methods may be defined in advance depending on what prerequisites are not met. That is, an error handling routine suitable for the cause of non-fulfillment of the preceding condition and the result of failure to execute the runnable is defined in advance, and can be appropriately used when a corresponding situation occurs.

At least one of various error handling methods may be performed in steps S630 to S650. For example, in some error situations, the occurrence of an error (non-satisfaction of a precondition) may be ignored, and the runnable execution may proceed as it is (step S630). According to another error handling method, it is determined that a seriously abnormal situation has occurred and the hardware may be reset (step S640). According to another error handling method, by notifying or externally reporting an error record, it is possible to induce a user or manager of the vehicle to take a specific action (step S650).

Up to now, with reference to FIGS. 3 to 8 , a method for managing to keep the execution order of application runners in the Otosa platform according to an embodiment of the present invention, and an exemplary data structure of an event chain that can be used in the method , an exemplary data structure that defines the prerequisites for execution of a runnable, a data structure of an identifier for recording an event, and the like have been described.

According to the present embodiment, in the Otosa platform executed by a plurality of control units such as multi-processors or multi-cores, it is possible to manage so that the execution order of runners is maintained among different control units. By implementing the above functions in the middleware layer between the BSW layer and the SWC layer of the Autosa platform, it is possible to manage the execution order of the application runners without modifying the application software running on the Autosa platform. In addition, by implementing the above functions in the middleware layer of the Otosa platform, when the execution order of application runners is not observed, in addition to hardware reset, error log recording, error notification, ignoring errors and running the runners, etc. It becomes possible to handle errors in an appropriate way according to various error occurrence situations.

Hereinafter, with reference to FIG. 9 , a process in which an execution order among application runners executed in two or more control units is managed in some embodiments of the present invention will be briefly described.

Referring to FIG. 9 , a control unit #1 (MCU; 900) that executes functions implemented in the Otosa Classic platform and a control unit #2 (CPU; 950) that executes functions implemented in the Ottosa adaptive platform are provided. The system is shown. According to some embodiments of the present invention, control unit #1 (900) by transmitting and receiving and synchronizing respective event chains via a network connecting between control unit #1 (900) and control unit #2 (950) It is possible to define and manage the execution order among the applications or runables 941 and 991 respectively executed in the control unit #2 950 and the control unit #2 950 .

For example, when a task that executes the runnable #1 941 is activated in the OS 911 running on the control unit #1 900 and the runnable #1 941 is called, the middleware 930 The preprocessing process 931 of the runnable #1 (941) execution is executed. In the pre-processing process 931 , the fact that the execution start of the RUNNABLE #1 ( 941 ) is started is recorded in the event chain #1 ( 935 ) of the control unit #1 ( 900 ), and the prerequisites for the execution of the RUNNABLE #1 ( 941 ) are satisfied. It is determined whether or not According to the determination result, the SWC 940 executes the runnable #1 941 , and upon completion of the execution, the middleware 930 executes the post-processing process 933 again. In the post-processing process 933 , the fact that the execution of the runnable #1 ( 941 ) has been completed is recorded in the event chain #1 ( 935 ) of the control unit #1 ( 900 ). Also, event chain #1 (935) is transmitted to control unit #2 (950) via the network, so that event chain #2 (985) of control unit #2 (950) is updated.

On the other hand, when the task for executing the runnable #2 (991) is activated in the OS 961 executed in the control unit #2 (950) and the runnable #2 (991) is called, the middleware (980) #2 (991) The preprocessing process 981 of the execution is executed.

In the preprocessing process 981 , the fact that the execution start of runner #2 ( 991 ) is started is recorded in event chain #2 ( 985 ) of control unit #2 ( 950 ), and the prerequisites for execution of runnerable #2 ( 991 ) are satisfied It is determined whether or not At this time, in the event chain #2 (985), since the record about the runners executed in the control unit #1 (900) is updated, the RUNNABLE to be executed before the RUNNABLE #2 (991) is a different control unit. Even if it is the runnable #1 (941) executed by the #1 (900), appropriate management of the execution order among the runners is possible.

According to the determination result, runable #2 991 is executed in SWC 990 , and when execution is completed, post-processing process 983 is executed again in middleware 980 . In the post-processing process 983 , the fact that the execution of the runnable #2 991 has been completed is recorded in the event chain #2 985 of the control unit #2 950 . Also, event chain #2 (985) is sent to control unit #1 (900) via the network, so that event chain #1 (935) of control unit #1 (900) is updated.

Hereinafter, with reference to FIG. 10 , an example in which the method for managing runable execution according to an embodiment of the present invention is applied to a driving assistance system will be described.

10 illustrates an example of distributing and processing sensor fusion logic to a CPU instead of an MCU in an Advanced Driver Assistance System (ADAS). System response time can be improved by distributing and processing a task with a high processing load, such as sensor fusion logic, to the CPU. In the application example shown in FIG. 10 , an event chain is shared between the MCU and the CPU, which are control units that are physically distinct from each other, so that the execution order between the runners can be managed.

Referring to FIG. 10 , when the execution of the runable 1003 that processes the vehicle dynamics signal in CORE #0 of the MCU is completed, the identifier of the completion event is recorded in the event chain of CORE #0 of the MCU, and the CORE # of the MCU The event chain of 0 is sent to CORE #1 of MCU, CORE #2 of MCU, and CPU, and merged into event chains of CORE #1, CORE 2, and CPU respectively.

When a function or runable 1007 that processes sensor fusion is called in the CPU, it is determined whether or not the vehicle dynamics signal processing runnable 1003, which should precede sensor fusion, is completed as a pre-processing process. Although the vehicle dynamics signal processing runnable 1003 was executed in CORE #0 of the MCU physically distinct from the CPU, after the execution, the event chain of the MCU CORE #0 in which the execution completion fact is recorded is transmitted to the CPU and , since the event chain of the CPU has been merged, it can be determined whether or not the runnable 1003 is complete, and an appropriate error handling routine can be executed according to the determination result. When the execution of the sensor fusion function or the runable 1007 in the CPU is completed, the execution completion is similarly recorded in the event chain of the CPU, and the event chain of the CPU is transferred to other control units (CORE #0, CORE #1, CORE of the MCU). #2) and merged into the respective event chains.

When the output processing runnable 1011 is called from CORE #0 of the MCU again, it is determined from the event chain whether the prerequisite is satisfied according to a method similar to the process described above, and then the output processing runner 1011 can be executed do.

The concepts of the present invention described with reference to FIGS. 1 to 10 may be implemented as computer-readable codes on a computer-readable medium. The computer-readable recording medium may be, for example, a removable recording medium (CD, DVD, Blu-ray disk, USB storage device, removable hard disk) or a fixed recording medium (ROM, RAM, computer-equipped hard disk). can The computer program recorded on the computer-readable recording medium may be transmitted to another computing device through a network such as the Internet and installed in the other computing device, thereby being used in the other computing device.

Although acts are shown in a particular order in the drawings, it should not be understood that the acts must be performed in the specific order or sequential order shown, or that all illustrated acts must be performed to obtain a desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of the various components in the embodiments described above should not be construed as necessarily requiring such separation, and the program components and systems described may generally be integrated together into a single software product or packaged into multiple software products. It should be understood that there is

Although embodiments of the present invention have been described with reference to the accompanying drawings, those of ordinary skill in the art to which the present invention pertains can realize that the present invention can be embodied in other specific forms without changing its technical spirit or essential features. you will be able to understand Therefore, it should be understood that the embodiments described above are illustrative in all respects and not restrictive.

Claims (16)

A method for managing runnable execution on an Ottosa platform, the method comprising:
obtaining prerequisites for execution of a plurality of runnables;
performing pre-processing for determining whether a prerequisite for execution of a first runner among the plurality of runners is satisfied;
executing the first runnable; and
performing post-processing of adding an event identifier indicating the completion of the first runnable execution to an event chain;
including,
Performing the pre-processing step,
identifying, from the prerequisites, identifiers of preceding events to be completed before the first runable; and
searching for identifiers of the preceding events in the event chain;
containing,
How to manage runnable execution on the Ottosa platform. According to claim 1,
The prerequisites for the execution of the plurality of runners are indicative of a precedence relationship of the execution of the plurality of runners.
How to manage runnable execution on the Ottosa platform. According to claim 1,
The prerequisites for the execution of the plurality of runables include information about one or more other runables to be executed before the first runable,
How to manage runnable execution on the Ottosa platform. According to claim 1,
The prerequisites for the execution of the plurality of runables are predefined using the event identifier,
The event identifier includes an identifier unique to the plurality of runables and an identifier indicating execution start or execution completion,
How to manage runnable execution on the Ottosa platform. According to claim 1,
Performing the pre-processing step,
and adding to the event chain an event identifier indicating the fact that the first runnable execution has started.
How to manage runnable execution on the Ottosa platform. According to claim 1,
The step of executing the first runnable comprises:
executing the first runnable based on the discovery of identifiers indicative of the fact of completion of the preceding events in the event chain;
How to manage runnable execution on the Ottosa platform. 7. The method of claim 6,
wherein the event chain is recorded in an ordered list,
How to manage runnable execution on the Ottosa platform. According to claim 1,
The performing the pre-processing and the performing the post-processing are performed by middleware,
Performing the pre-processing step,
detecting, by the middleware, the first runnable execution call; and
the middleware reading the event chain
including,
Performing the post-processing step,
detecting, by the middleware, completion of execution of the first runable;
adding, by the middleware, an event identifier indicating completion of the first runnable execution to the event chain;
containing,
How to manage runnable execution on the Ottosa platform. According to claim 1,
wherein the plurality of runables include a runable executed in a first control unit and a runable executed in a second control unit distinct from the first control unit,
How to manage runnable execution on the Ottosa platform. 10. The method of claim 9,
the first runable is executed in a first control unit;
Performing the post-processing step,
sending, by the first control unit, the event chain to the second control unit;
further comprising,
How to manage runnable execution on the Ottosa platform. 10. The method of claim 9,
the first runable is executed in a first control unit;
merging, by the first control unit, the event identifier received from the second control unit into the event chain;
further comprising,
How to manage runnable execution on the Ottosa platform. 10. The method of claim 9,
The event identifier is
Further comprising an identifier for distinguishing from each other a plurality of control units comprising the first control unit and the second control unit,
How to manage runnable execution on the Ottosa platform. According to claim 1,
executing a predefined error handling routine based on a determination that the prerequisite of the first runnable execution is not met;
further comprising,
How to manage runnable execution on the Ottosa platform. 14. The method of claim 13,
The predefined error handling routine is defined differently for different runables,
How to manage runnable execution on the Ottosa platform. 14. The method of claim 13,
The predefined error handling routine is defined differently for different prerequisites,
How to manage runnable execution on the Ottosa platform. As a storage medium on which a runable execution management program on the Ottosa platform is recorded,
The program is
an instruction for obtaining prerequisites for execution of a plurality of runables;
instructions for performing pre-processing to determine whether a prerequisite for execution of a first runner among the plurality of runners is satisfied;
instructions for executing the first runnable; and
Instructions for performing post-processing of adding an event identifier indicating the fact that the first runnable execution has been completed to an event chain
including,
The instruction for performing the pre-processing is,
an instruction for identifying, from the prerequisites, identifiers of preceding events to be completed before the first runnable; and
an instruction to search for identifiers of the preceding events in the event chain
comprising,
A storage medium on which a program is recorded.

Images