KR20140066531A - A component architecture based on autosar(automotive open system architecture) - Google Patents

Abstract

An AUTOSAR-based component structure according to an embodiment of the present invention includes a plurality of application components, a plurality of runables interlocked with the plurality of application components, and a plurality of run- And a first component including a hub runlevel. Accordingly, it is possible to reduce the occurrence of load, increase data processing speed, and utilize efficient resources.

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a component architecture based on AUTOSAR (AUTOMOTOR OPEN SYSTEM ARCHITECTURE)

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a component structure based on the AUTOSAR standard, and more particularly, to an AUTOSAR-based component structure having a component and an interface capable of efficiently processing a load due to an increase in input / output between components.

BACKGROUND ART [0002] In recent years, automobiles include devices such as an engine, an automatic transmission, a braking device (ABS), a steering system, and an ECU (Electronic Control Unit) for controlling these devices. Also, as the number of intelligent services increases, more ECUs are connected, and services are connected through interworking of connected ECUs

Accordingly, in order to set up and develop open industry standards for automotive ECUs, related companies have jointly proposed software architecture standards such as AUTomotive Open System ARchitecture (AUTOSAR).

AUTOSAR is concerned with automotive software specifications and execution environment. It provides architecture for vehicle field software, and application programming interface (API) for each field application.

In recent years, software has become increasingly complicated as the functions to be mounted become more and more complicated, and the input / output between the components is increasing.

Thus, there is a need for a component and interface design that can handle loads more efficiently.

It is an object of the present invention to provide a component structure having a further improved performance and a component structure based on the AUTOSAR standard according to an interface design.

An AUTOSAR-based component structure according to an embodiment of the present invention includes a plurality of application components, a plurality of runables interlocked with the plurality of application components, and a plurality of run- And a first component including a hub runlevel.

According to the embodiment of the present invention, it is possible to reduce the occurrence of load, increase data processing speed, and utilize efficient resources.

Figure 1 is a block diagram illustrating the layered software architecture of AUTOSAR.
FIG. 2 is a diagram illustrating an AUTOSAR-based component structure according to an embodiment of the present invention.
3 is a diagram illustrating an interface according to an embodiment of the present invention.

Hereinafter, the present invention will be described in detail with reference to the drawings.

The suffix "module" and " part "for components used in the following description are given merely for convenience of description, and do not give special significance or role in themselves. Accordingly, the terms "module" and "part" may be used interchangeably.

Figure 1 is a block diagram illustrating the layered software architecture of AUTOSAR.

Referring to FIG. 1, the layered software architecture of AUTOSAR is divided into a basic software layer (BSW) 110, an application software layer 130, and a run time environment (RTE) 140 Layered structure.

The basic design of the AUTOSAR is to introduce an RTE concept to separate the application SW-C (software component) and the BSW layer 110, which is a software layer related to the hardware 120, to develop an application service independent of the hardware 120 will be.

Meanwhile, the BSW 110 is a standardized software layer that provides a service required by a software component to perform necessary tasks, and provides services related to input / output, memory, communication, and the like to AUTOSAR Software components. The BSW 110 is subdivided into a service layer, an ECU abstraction layer (EAL), a microcontroller abstraction layer (MCAL), and a composite driver.

The service layer is a layer that includes communication, service, and OS blocks, and abstracts the ECU and hardware to provide services for the application program and the BSW (110) module to its upper layer. Memory, communication network, and system.

The communication network service of the service layer provides a unified communication method to the RTE 140 as a layer for providing a unified interface that removes the dependency on the lower communication device. Communication network services consist of SW-C functions such as vehicle network communication such as CAN, LIN, FlexRay, etc., communication driver interface such as communication hardware abstraction, vehicle network interface for communication between different applications.

The memory service of the service layer provides the function to read and write to various recording memories. In the memory service, the SW-SW functions to manage nonvolatile memory for diary / writing from other memory service, memory location and property abstraction, C

And the EAL / MCAL part is a part that is changed depending on the hardware 140, and it must be changed together with appropriate software whenever the hardware 120 is changed. That is, the EAL can be changed according to the ECU circuit, and the MCAL can be changed depending on the microcontroller (MCU) to be used.

On the other hand, the MCAL portion is a portion that handles direct access to peripherals, internal / external devices, memory, etc. included in the actual hardware. Therefore, it plays an important role in problems such as timing because it accesses hardware directly.

MCAL layer has hardware dependency. It is composed of communication driver of OSI data link layer, analog digital I / O driver such as ADC, PWM, DIO, memory driver such as EEPROM, Flash and device driver area of peripheral microcontroller. .

The HAL (Hardware Abstraction Layer) layer is a layer that provides transceivers or interface drivers that can use the MCAL at the MCAL top of each device. This is independent of the microcontroller, but it depends on the ECU board to be used, and is a hierarchy dependent on external communication devices, IO devices, and memories.

On the other hand, when developing a special function, a compound driver can be used when it is necessary to directly access the hardware in the application software layer.

The RTE 140 plays a pivotal role in communication for managing data exchange. Since the software components based on the RTE 140 have unique communication constraints depending on the type of the application program, the RTE must also be configured to such a constraint.

Each SW-C implements a part of the application SW function and exchanges mutual data through port and interface as a basic unit which is mapped to ECU. Sensor / Actuator SW-C is a kind of SW-C, which is SW-C for the implementation of ECU sensor and actuator.

The RTE 140 plays a pivotal role in exchanging information between SW-Cs and between SW-C and BSW, and plays a key role in separating SW and HW. That is, the RTE 140 serves as a communication bridge between the application layer and the lower SW component module to remove the independence of the HW from the application SW-C. The RTE 140 performs various mapping processes to the ECU from the SW- And other components.

Meanwhile, these components can perform communication through a virtual network called VFB (Virtual Function Bus) at the design stage, and the components allocated to the ECU can exchange information with each other through the RTE 140 existing in each ECU at runtime And can perform necessary operations.

 The application software layer, i.e., the application layer 130, is a layer composed of AUTOSAR software components mapped to a specific ECU. The application software layer 130 is implemented independently of a hardware layer such as a microcontroller and communicates with all the resources of the lower layer through the RTE 140. At this time, each component module uses AUTOSAR interface to transmit and receive necessary data through RTE.

 The application software component and the actuator software component process the control logic of the system, the sensor component acts as a hardware-dependent interface of the input part, and the actuator component controls the hardware dependent output part. Accordingly, each software component exchanges mutual data through a port and an interface as a basic unit mapped to an ECU that implements the corresponding application software function.

The AUTOSAR specification stipulates that application software and RTE are strictly defined through this layered software architecture, thereby maintaining software reusability and scalability, and supporting rapid and reliable development of software.

However, in the standard specification of AUTOSAR, the MCAL, the requirements of the software components and the design methodology are not specifically defined, and an optimized design is required.

FIG. 2 is a diagram illustrating an AUTOSAR-based component structure according to an embodiment of the present invention, and FIG. 3 is a diagram illustrating an interface according to an embodiment of the present invention.

Referring to FIG. 2, an AUTOSAR-based component structure according to an embodiment of the present invention includes a plurality of application components 1, 2, ...,

A first component including a plurality of runables (runable 1, 2, 3, ... n) interlocked with the plurality of application components, and a hub runable (A) for transmitting and receiving data with the plurality of runables, .

Here, the plurality of application components may be software components (SW-C).

Among the components that are the basic unit of AUTOSAR, the component that becomes the basic unit of the application program is called the software component (SW-C). SW-C becomes the execution unit of the application program. It is infrastructure independent and can be mapped to one ECU.

Meanwhile, the first component may be a sensor software component that receives sensing information.

In addition, the first component may be an Actuator Software Component that outputs a control value for a predetermined operation. Sensor / actuator SW-C is a special case of SW-C that contains information encapsulating the dependence of specific sensors and actuators.

The actuator software component processes the control logic of the system, the sensor component acts as a hardware-dependent interface of the input, and the actuator component controls the hardware-dependent output. Accordingly, each software component exchanges mutual data through a port and an interface as a basic unit mapped to an ECU that implements the corresponding application software function.

On the other hand, the logical interconnection of the components can be packaged as one component, and this package is called a composition.

The Sensor / Actuator Component can be H / W controlled using the API provided by MCAL. Application components may have component features that are connected to the BSW 110 or other components via the RTE 140 and in which the application is implemented.

Each component sends and receives data through a port according to interface attributes. At this time, the ports of the same interface can be connected to each other, and the interface attribute can be a standard interface of AUTOSAR of a sender-receiver or a client-server.

The runnable is operated through the RTE 140 and the data transfer between runnables can be performed through an Inter Runnable Variable.

The API of MCAL can be used in Runnable of Sensor / Actuator Component.

According to the present invention, it is possible to reduce the occurrence of loads, increase data processing speed, and utilize resources efficiently.

In particular, the present invention can more efficiently connect the interface between the application component and the sensor / actuator component.

In addition, the present invention reduces the occurrence of load that can occur due to an increase in input / output relationship between a sensor / actuator component and an application component in the development of a component based on the AUTOSAR standard, Design.

Meanwhile, the plurality of runables and the hub runle A may communicate with each other through an inter-runable variable.

Each of a plurality of application components according to an embodiment of the present invention may be connected to a sensor / actuator component and a client-server interface.

In addition, the components may include one or more runnables, and each runlevel may interwork with other software components, such as through a port or a service port. Also, even within one software component, each runable can send and receive data via an Inter Runnable Variable.

On the other hand, each port may be composed of one or more data elements or operations.

Referring to FIG. 2, the hub run A is connected to a plurality of runables 1, 2, 3.

The hub run A can periodically read the input of the external port or transmit the output value using the MCAL API as a timing event of the periodic attribute.

The hub runnable A and the runnable 1, 2, 3 .. n can be connected by an inter-runnable variable.

The hub runable (A) can transmit and receive data to and from a MCAL (Microcontroller Abstraction Layer) layer.

Runnables 1, 2, 3... N may be Event Runnable by a client-server interface.

In addition, the plurality of application components and the first component may be connected to the client-server interface.

Figure 3 illustrates client-server communication from a VFS perspective.

For application relocation, AUTOSAR SW-C is hardware-independent. A hardware-independent implementation is possible by using a virtual functional bus (VFB). VFB is a tool for mapping virtual hardware and independent system integration.

Every component has a well-defined port, which communicates with other components through this port. The interface between the port and the port that is the basis of the communication of the component may be PPort which is the port providing the AUTOSAR interface and RPort which is the port which requires the AUTOSAR interface.

As shown in FIG. 3, one or more clients may exist in one server. Since the port of the client is RPort and the port of the server is PPort, the server provides the service requested by the client.

Referring to FIG. 2, when an event of runnables 1, 2, 3,... N occurs according to a write operation condition of an application component, an inter- Runnable Variable).

The runnable A of the periodic attribute reads the Inter Runnable Variable and calls the MCAL API for writing the port.

In this case, when a sensor / actuator component is called from an application component, a parameter of an interface may indicate a value of a corresponding port to be controlled.

 When an event in a runable occurs due to a read operation condition of an application component, a port (Port) read using a MCAL API in a run-time-attribute runnable A, ), That is, the value stored in the Inter Runnable Variable is read from Runnable 1, 2, 3, ... n.

At this time, when the sensor / actuator component is called from the application component, the return of the interface is the value of the port stored in the inter-runnable variable .

The AUTOSAR-based component structure according to an embodiment of the present invention includes a plurality of runables interlocked with the plurality of application components, and a hub run-able to transmit and receive data with the plurality of run-ins.

Also, the MCAL can be input / output at once through the hub run A, so that the load can be reduced and the processing speed can be increased as compared with a case where a plurality of runables are called individually.

According to the embodiment of the present invention, it is possible to reduce the occurrence of load, increase data processing speed, and utilize efficient resources.

In particular, the present invention can more efficiently connect the interface between the application component and the sensor / actuator component.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, but, on the contrary, It will be understood by those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the present invention.

110: BSE
120: Hardware layer
130: application software layer
140: RTE

Claims (6)

A plurality of application components;
And a first component including a plurality of runables interworking with the plurality of application components and a hub runlable for transmitting and receiving data between the plurality of runlables and the plurality of runtables. The method according to claim 1,
Wherein the first component is a sensor component that receives sensing information. The method according to claim 1,
Wherein the first component is an actuator component that outputs a control value for a predetermined operation. The method according to claim 1,
Wherein the plurality of application components and the first component are connected to the client-server interface. The method according to claim 1,
Wherein the plurality of runables communicate with the hub runle with an inter runable variable. The AUTOSAR-based component structure according to claim 1, wherein the hub runlable transmits and receives data to and from a microcontroller abstraction layer (MCAL) layer.

Images