KR20130088990A - Apparatus and method for middleware - Google Patents

Abstract

PURPOSE: Middleware device and method are provided to easily install and use a new application and to check stability of the installed application. CONSTITUTION: A master electronic control unit (ECU) (100) analyzes inputted application and generates a task generation message. Slave ECUs (310,330) analyzers the task generation message and generates a new task. The master ECU prepares a parsing unit (110) parsing the application and generating a software component (SWC) list and SWC mapping information and a task message generation unit (130) generating the task generation message. The task message generation unit adds an indicator for identifying the task generation message to a header of the task generation message. [Reference numerals] (110) Parsing unit; (130) Task message generating unit; (150) Stability analysis unit; (311,BB) Receiving unit; (313,CC) Task generating unit; (315,DD) Task storage unit; (AA) New vehicle application

Description

Middleware Devices and Methods {APPARATUS AND METHOD FOR MIDDLEWARE}

Embodiments relate to a middleware device and method, and more particularly, to a middleware device and method capable of installing a new application.

ECU (Electronic Control Unit) refers to an electronic control device that controls the state of the engine, automatic transmission, ABS, etc. of the vehicle with a computer.

When the ECU was developed, the goal was to precisely control the engine's key functions such as ignition timing, fuel injection, idling and limit value settings. However, with the development of automobile and computer performance, it is in charge of controlling all parts of the car such as drive system, braking system and steering system as well as automatic transmission control. Therefore, there are many kinds of ECUs in automobiles, which requires a method of managing many ECUs at once. Therefore, in the past, many ECUs were managed by using middleware for automobiles.

A typical automotive middleware is AUTO (Automotive Open System Architecture, AUTOSAR). Otto is a vehicle software specification and execution environment designed for common use by automakers. Otto was developed around European automakers such as BMW, Bosch, Continental and DaimerChrysler. Typical Auto products include 3Soft's tresosECU, LiveDevices' RTA, and Vector's DaVinci. Otto is one of the standardized integrated software platforms to tackle the complexity of hardware (HW) or ECC-dependent software (SW) as automotive electronics become more complex.

1 is an architecture of Otto.

Referring to FIG. 1, the architecture of Otto Corporation is composed of software component (SW-Component), AUTOSAR RTE, Basic Software and Microcontroller Abstraction. Here, Microcontroller Abstraction is a module that implements device drivers to actually run a specific device.

Otto assumes that several ECUs are networked in a vehicle, and that one or several Microcontrollers and multiple devices (RAM, Flash, network, I / O) work within an ECU.

By separating the layers of automotive SW and HW, Otto maximizes the reusability of automotive SW, and has shortened the vehicle development period and reduced costs.

Middleware applied to recently released cars is a structure that can not install new SW or HW. That is, it is difficult for a user to apply a new option later in addition to the pre-installed option. For example, recently, energy-efficient vehicles have been introduced. Algorithms for energy efficiency or carbon dioxide reduction can be applied only to newly manufactured cars, but not to existing vehicles. In addition, another example of the recently released cars are user-defined (User-defined) cars, it is difficult to install the SW or HW that the user wants to be released later in accordance with the user's taste.

An ECU mounted on a vehicle having a conventional auto company operates with one executable file even when numerous SWCs are mounted inside the vehicle. Here, SWC stands for Software-Component, which is a part of an “Automobile application,” and refers to a minimum unit component that can operate in one ECU. And automotive applications are run by ECUs that are distributed inside the vehicle. For example, the 'automatic parking application' is performed by the sensor unit, the control unit, the driving unit, the selection unit, and the correction unit of the vehicle communicating with each other and performing their respective roles. In summary, automotive applications have a decentralized network structure inside the vehicle, whereby distributed ECUs control the vehicle through communication with each other. One automotive application operates with one SWC or a combination of multiple SWCs operating within one or multiple ECUs.

Since the ECU operates with one executable file, there is a problem that dependencies exist between tasks installed in the ECU. For example, if one SWC needs to be changed, the executable file of the ECU itself must be changed. Here, a task means one SWC or a plurality of SWCs operating in one ECU.

2 is a view illustrating a process of developing a vehicle application using a conventional auto company.

Referring to FIG. 2, the automotive software in AUTOSAR is modularized by component. These components are configured at the design stage to communicate with each other via a virtual network called a Virtual Functional Bus (VFB). The mapping phase then determines which ECUs each component will perform on. The components assigned to these ECUs perform necessary tasks by exchanging information with each other through a run-time environment (RTE) existing in each ECU at runtime. During this process, configuration files are written that record the properties and constraints of each software component and each ECU in the vehicle.

Korean Patent Publication No. 2010-0062787 (Published: 2010.06.10)

The embodiment provides a middleware device and a method in which a new application can be easily installed and used (Plug & Play).

In addition, the embodiment provides a middleware device and method that can check the stability problem when the application is installed.

According to an embodiment of the present disclosure, a middleware device may include: a master ECU configured to analyze a new input application to generate a task occurrence message; And a slave ECU that receives the task occurrence message and analyzes the received task occurrence message to generate a new task.

Here, the master ECU, the parser for parsing the application to generate a SWC list and SWC mapping information; And a task message generator configured to generate the task occurrence message by using the SWC list and the SWC mapping information.

Here, the task message generator may add a predetermined indicator for identifying the task occurrence message to a header of the task occurrence message.

Here, the master ECU may further include a stability analysis unit for checking the stability of the task installed in the slave ECU and the task to be installed.

Here, the stability analyzer may perform a schedule likelihood analysis.

Here, the application may be a workflow description.

Here, the slave ECU may include a receiving unit which receives a predetermined message from the master ECU and identifies whether the received message is the task occurrence message; A task generator configured to analyze the task occurrence message and generate a SWC list and the new task; And a task storage unit for storing the new task.

Here, the receiver may identify the task occurrence message by determining whether a predetermined indicator is present in the header of the received message.

According to another embodiment of the present disclosure, a middleware method includes: generating a task occurrence message by analyzing an input new application; And a task generation step of generating a new task by analyzing the task occurrence message.

The task generation message generating step may include: parsing the application to generate a SWC list and SWC mapping information; And generating the task occurrence message by using the SWC list and the SWC mapping information.

The method may further include adding a predetermined indicator to the header of the task occurrence message.

Here, when the task occurrence message is generated, the method may further include checking stability of the installed task and the task to be installed.

Here, the checking of the stability may use a schedulability analysis.

Here, the application may be input in the form of a workflow description.

The task generating step may include an identification step of identifying whether the task occurrence message is generated; Generating the SWC list and the new task by analyzing the task occurrence message; And a storing step of storing the new task.

Here, the identifying may determine whether a predetermined indicator is present in the header of the task occurrence message.

Using the middleware device and method according to the embodiment, there is an advantage that a new application can be easily installed and used (Plug & Play).

In addition, there is an advantage that can check the stability problem when the application is installed.

1 is an architecture of Otto Corporation.
2 is a view illustrating a process of developing a vehicle application using a conventional auto company.
3 is a block diagram of a middleware device according to an embodiment.
4 is an example of a workflow description.
5 is an example of task occurrence message generation.
6 is an example for explaining the operation of the first slave ECU.
7 is an architecture showing an example in which the middleware device shown in FIG. 3 is implemented.
8 is a flow chart for explaining the operation of the master ECU shown in FIG.
9 is a flow chart for explaining the operation of the first slave ECU shown in FIG.

The thickness and size of each layer in the drawings are exaggerated, omitted, or schematically shown for convenience and clarity of explanation. In addition, the size of each component does not necessarily reflect the actual size.

In the description of the embodiment, when one element is described as being formed on an "on or under" of another element, it is on (up) or down (on). or under) includes two elements in which the two elements are in direct contact with each other or one or more other elements are formed indirectly between the two elements. Also, when expressed as "on or under", it may include not only an upward direction but also a downward direction with respect to one element.

Hereinafter, a middleware device according to an embodiment will be described with reference to the accompanying drawings. The following embodiment is taken as an example of a vehicle middleware device, the middleware device of the present invention is not limited to the vehicle middleware device.

3 is a block diagram of a middleware device according to an embodiment, and FIG. 7 is an architecture illustrating an example in which the middleware device shown in FIG. 3 is implemented.

Referring to FIG. 3, the middleware device according to the embodiment includes a master ECU 100 and a slave ECU 310 and 330. Here, two slave ECUs 310 and 330 are shown for convenience of description, but the present invention is not limited thereto. That is, the number of slave ECUs 310 and 330 may be one or more than three. The number of slave ECUs 310, 330 may be further increased depending on the number of ECUs required by the new automotive application.

The master ECU 100 manages all automotive applications installed in the vehicle. The master ECU 100 is responsible for installing and deleting new vehicle applications. In addition, the master ECU 100 can also perform stability checks of new automotive applications.

In detail, the master ECU 100 may include a parser 110 and a task message generator 130. The newly installed vehicle application is input to the master ECU 100. Here, the input car application may be in the form of a workflow description. For example, the workflow description may be an XML file, as shown in FIG. 4. In addition, the automotive application may be a kind of flowchart.

The parsing unit 110 receives a workflow description. The parser 110 parses the input workflow description. The parser 110 parses the workflow description to generate a SWC list. Table 1 below is an example of a SWC list generated by parsing the XML file illustrated in FIG. 4. The SWC list may be listed in the order in which the SWCs are performed.

strID strName strECUIP strPeriod One Master 192.168.0.3 0 2 MDPS 192.168.0.6 0 ... 5 L_VM 192.168.0.4 100 (ms) ...

In addition, the parser 110 parses the workflow description to generate SWC mapping information. The SWC mapping information is information on a connection relationship between SWCs and may be information about a part 410 of the XML file illustrated in FIG. 4. Here, the SWC mapping information may be mapping information of SWCs to be performed in the first slave ECU 310 or SWC and second slave ECU 330 to be performed by the first slave ECU 310. It may also be connection information of the SWC to be performed by.

The parser 110 outputs the generated SWC list and the SWC mapping information to the task message generator 130.

The task message generator 130 receives the SWC list and the SWC mapping information from the parser 110.

The task message generator 130 generates a task generation message using the SWC list and the SWC mapping information. More specifically, the task message generator 130 classifies the SWC list and the SWC mapping information by the slave ECUs 310 and 330. Information corresponding to any one slave ECU is included in one task occurrence message. 5 is an example of a process of generating a task occurrence message.

The task message generator 130 generates a task occurrence message for each of the slave ECUs 310 and 330, and transmits the generated task occurrence messages to each slave ECUs 310 and 330.

Here, the task message generator 130 may add a predetermined indicator to the header in the generated task occurrence message. This is for the slave ECU 310 receiving the message to identify the task occurrence message. Referring to FIG. 5, the task message generator 130 adds <run> to the header as an indicator to indicate that the generated message is a task occurrence message.

On the other hand, since the automobile is closely related to the life of a person, it is very important to ensure the real time of the tasks performed in the slave ECUs (310, 330). Accordingly, the master ECU 100 may have a stability analyzer 150 to check the stability of the slave ECUs 310 and 330.

The stability analyzing unit 150 analyzes the tasks installed in each of the slave ECUs 310 and 330 and the stability of the task to be installed. For example, the stability analyzer 150 may perform a scheduleability analysis on tasks installed in the slave ECUs 310 and 330 and tasks to be installed. The schedulability analysis uses three parameters, for example, worst-case execution time (WCET), deadline, and priority, to ensure that all tasks perform their actions on time. Check if you can. Through the stability analysis unit 150, it is possible to ensure the reliability for automotive applications.

Slave ECUs 310 and 330 are ECUs that perform either function in a vehicle. For example, the slave ECUs 310 and 330 may be ECUs related to a motor driving power steering (MDPS) system. For example, the first slave ECU 310 may be a Left_Motor ECU.

The first and second slave ECUs 310 and 330 receive a task occurrence message from the master ECU 100. The first and second slave ECUs 310 and 330 generate new tasks using the task occurrence message. Hereinafter, the configuration of the first slave ECU 310 will be described in detail. Here, since the second slave ECU 330 is the same as the first slave ECU 310, detailed description of the second slave ECU 330 will be omitted.

The first slave ECU 310 may include a receiver 311, a task generator 313, and a task storage unit 315.

The receiver 311 determines whether a message input from the master ECU 100 is a task occurrence message. To distinguish this, the receiver 311 checks a header of an input message. If there is an indicator (<run>) indicating that the message is a task occurrence message in the header of the input message, the receiver 311 recognizes the corresponding message as a task occurrence message and recognizes the task occurrence message as a task generator. Forward to 313. On the other hand, if there is no indicator indicating a task occurrence message in the header of the input message, the receiver 311 recognizes the message as a task execution message, and delivers the task execution message to the task storage unit 315.

The task generator 313 receives a task occurrence message from the receiver 311. The task generator 313 parses and analyzes a task occurrence message, generates a new SWC list, and generates a new task that performs the generated SWC list. Here, the new task may be generated through a task template. The task template may also play a role of sequentially executing a SWC list.

The task generator 313 stores the generated new task in the task storage unit 315. For example, as shown in FIG. 6, the task generator 313 allows a new task named VM2 to be stored in the task storage unit 315 from the task occurrence message shown in FIG. 5. Here, the VM2 task may be a task for performing a SWC for acquiring the PWM and a SWC for transmitting the acquired PWM.

The task storage unit 315 stores a task execution message input from the receiver 311. In addition, the task storage unit 315 stores a new task input from the task task generator 313. Here, the task storage unit 315 may store the input information in one of a list, a queue, and an array.

The task storage unit 315 executes internal tasks according to the task execution message stored in the task storage unit 315.

8 is a flowchart for describing an operation of the master ECU illustrated in FIG. 3.

3 and 8, when the workflow description is input 810 to the master ECU 100, the parser 110 parses the workflow description and generates a SWC list according to the operation sequence of the SWCs ( 820). Here, the parser 110 may also generate SWC mapping information. The parser 110 transmits the generated SWC list and the SWC mapping information to the task message generator 130.

Based on the SWC list and the SWC mapping information, the task message generator 130 generates a task occurrence message including the linkage information of the SWCs for each of the slave ECUs 310 and 330 (830). The task occurrence message may be sent directly to the slave ECU or stability analysis may be performed before transmission.

When the stability analysis is performed, the stability analysis unit 150 performs stability analysis of the slave ECU to which the generated task occurrence message is transmitted. When a new task is installed in the corresponding slave ECU, the stability analysis may determine whether the existing task and the new task can be scheduled (840). If, as a result of the stability analysis, the schedule is possible, the task message generating unit 130 transmits the generated task occurrence message to the corresponding slave ECU (310, 330) (850), the slave ECU received the task occurrence message ( In step 310, the mobile terminal receives the transmission completion message from 310 and 330. On the other hand, if the scheduling is not possible, the task message generator 130 does not transmit the generated task occurrence message to the corresponding slave ECUs 310 and 330, and notifies the user that installation is impossible (870).

FIG. 9 is a flowchart for describing an operation of the first slave ECU illustrated in FIG. 3.

When the first slave ECU 310 receives a predetermined message from the master ECU 100 (910), the receiver 311 determines whether the received message is a task occurrence message (920). Whether the received message is a task occurrence message may be determined by whether an indicator exists in the header of the received message.

As a result of the determination, when the received message is a task occurrence message, the receiver 910 transmits the task occurrence message to the task generator 313, and the task generator 313 parses and analyzes the task occurrence message (930). . The task generator 313 generates a new SWC list from the task occurrence message and generates a new task for performing the generated SWC list (940). Here, the generated SWC list is information containing the execution order of the plurality of SWCs, and a new task may be generated through a task template. Next, the task generator 313 stores the generated task in the task storage unit 315 (950).

On the other hand, if the received message is not a task occurrence message, the receiver 910 determines the received message as a task execution message, delivers the task execution message to the task storage unit 315 and stores it in the task storage unit 315. (960). Here, the task execution message may be input to an event queue of the task storage unit 315. Next, the task storage unit 315 executes a task execution message to execute internal tasks (970).

Although the above description has been made with reference to the embodiments, these are only examples and are not intended to limit the present invention, and those of ordinary skill in the art to which the present invention pertains should not be exemplified above without departing from the essential characteristics of the present embodiments. It will be appreciated that many variations and applications are possible. For example, each component specifically shown in the embodiments can be modified and implemented. It is to be understood that all changes and modifications that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

100: master ECU
110: parser
130: task message generator
150: stability analysis unit
310, 330: slave ECU
311: receiving unit
313: task generator
315: task storage unit

Claims (16)

A master ECU for analyzing the inputted new application and generating a task occurrence message; And
A slave ECU which receives the task occurrence message and analyzes the received task occurrence message to generate a new task;
Middleware device comprising a. The method of claim 1, wherein the master ECU,
A parser configured to parse the application to generate a SWC list and SWC mapping information; And
And a task message generator configured to generate the task occurrence message using the SWC list and the SWC mapping information. 3. The method of claim 2,
The task message generating unit adds a predetermined indicator for identifying the task occurrence message to a header of the task occurrence message. The method of claim 2, wherein the master ECU,
The middleware device further comprises a stability analysis unit for checking the stability of the task installed in the slave ECU and the task to be installed. The method of claim 4, wherein
The stability analysis unit middleware device for performing a schedulability analysis. The method of claim 1,
The application is a middleware device that is a workflow description. The method of claim 1, wherein the slave ECU,
A receiving unit which receives a predetermined message from the master ECU and identifies whether the received message is the task occurrence message;
A task generator configured to analyze the task occurrence message and generate a SWC list and the new task; And
A task storage unit for storing the new task;
Middleware device comprising a. The method of claim 7, wherein
And the receiving unit identifies the task occurrence message by determining whether a predetermined indicator is present in a header of the received message. Generating a task occurrence message by analyzing the inputted new application and generating a task occurrence message; And
A task generation step of generating a new task by analyzing the task occurrence message;
Middleware method comprising a. The method of claim 9, wherein the generating of the task occurrence message comprises:
Parsing the application to generate a SWC list and SWC mapping information; And
Generating the task occurrence message by using the SWC list and the SWC mapping information;
Middleware method comprising a. 11. The method of claim 10,
And adding a predetermined indicator to the header of the task occurrence message. 11. The method of claim 10,
If the task occurrence message is generated, the middleware method further comprises the step of checking the stability of the installed task and the task to be installed. 13. The method of claim 12,
Checking the stability comprises a middleware method using scheduleability analysis. The method of claim 9,
The application is a middleware method that is input in the form of a workflow description. The method of claim 9, wherein the task generation step,
An identification step of identifying whether the task occurs message;
Generating the SWC list and the new task by analyzing the task occurrence message; And
A storing step of storing the new task;
Middleware method comprising a. The method of claim 15,
The identifying step is a middleware method for determining whether a predetermined indicator is present in a header of the task occurrence message.

Images