KR20140066531A - A component architecture based on autosar(automotive open system architecture) - Google Patents
A component architecture based on autosar(automotive open system architecture) Download PDFInfo
- Publication number
- KR20140066531A KR20140066531A KR1020120133894A KR20120133894A KR20140066531A KR 20140066531 A KR20140066531 A KR 20140066531A KR 1020120133894 A KR1020120133894 A KR 1020120133894A KR 20120133894 A KR20120133894 A KR 20120133894A KR 20140066531 A KR20140066531 A KR 20140066531A
- Authority
- KR
- South Korea
- Prior art keywords
- component
- autosar
- software
- application
- layer
- Prior art date
Links
Images
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Human Computer Interaction (AREA)
- Mechanical Engineering (AREA)
- Communication Control (AREA)
Abstract
Description
BACKGROUND OF THE
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
The basic design of the AUTOSAR is to introduce an RTE concept to separate the application SW-C (software component) and the
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
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
The application software layer, i.e., the
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
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
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
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
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.
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
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
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)
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.
Wherein the first component is a sensor component that receives sensing information.
Wherein the first component is an actuator component that outputs a control value for a predetermined operation.
Wherein the plurality of application components and the first component are connected to the client-server interface.
Wherein the plurality of runables communicate with the hub runle with an inter runable variable.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020120133894A KR20140066531A (en) | 2012-11-23 | 2012-11-23 | A component architecture based on autosar(automotive open system architecture) |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020120133894A KR20140066531A (en) | 2012-11-23 | 2012-11-23 | A component architecture based on autosar(automotive open system architecture) |
Publications (1)
Publication Number | Publication Date |
---|---|
KR20140066531A true KR20140066531A (en) | 2014-06-02 |
Family
ID=51123232
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020120133894A KR20140066531A (en) | 2012-11-23 | 2012-11-23 | A component architecture based on autosar(automotive open system architecture) |
Country Status (1)
Country | Link |
---|---|
KR (1) | KR20140066531A (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105137943A (en) * | 2015-09-06 | 2015-12-09 | 同济大学 | Micro hybrid power system integrated control software framework |
KR20160071260A (en) * | 2014-12-11 | 2016-06-21 | 현대자동차주식회사 | Method for managing state of ECU in vehicle based on automotive open system architecture |
KR20160081508A (en) * | 2014-12-31 | 2016-07-08 | 현대모비스 주식회사 | Interface apparatus for AUTOSAR setup |
KR20160087274A (en) * | 2015-01-13 | 2016-07-21 | 현대모비스 주식회사 | An Electronic Control Unit multi-core architecture based on AUTOSAR(AUTomotive Open System Architecture) and Vehicle including the same |
KR20170114521A (en) * | 2016-04-05 | 2017-10-16 | 현대모비스 주식회사 | Apparatus and method for MDPS MCU core fault detection |
WO2021047970A1 (en) | 2019-09-10 | 2021-03-18 | Volkswagen Aktiengesellschaft | Software components for a software architecture |
CN112783736A (en) * | 2021-03-01 | 2021-05-11 | 苏州挚途科技有限公司 | Method and device for monitoring running body time of software component and electronic equipment |
-
2012
- 2012-11-23 KR KR1020120133894A patent/KR20140066531A/en not_active Application Discontinuation
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20160071260A (en) * | 2014-12-11 | 2016-06-21 | 현대자동차주식회사 | Method for managing state of ECU in vehicle based on automotive open system architecture |
KR20160081508A (en) * | 2014-12-31 | 2016-07-08 | 현대모비스 주식회사 | Interface apparatus for AUTOSAR setup |
KR20160087274A (en) * | 2015-01-13 | 2016-07-21 | 현대모비스 주식회사 | An Electronic Control Unit multi-core architecture based on AUTOSAR(AUTomotive Open System Architecture) and Vehicle including the same |
CN105137943A (en) * | 2015-09-06 | 2015-12-09 | 同济大学 | Micro hybrid power system integrated control software framework |
CN105137943B (en) * | 2015-09-06 | 2018-06-26 | 同济大学 | A kind of micro-hybrid system integration control device |
KR20170114521A (en) * | 2016-04-05 | 2017-10-16 | 현대모비스 주식회사 | Apparatus and method for MDPS MCU core fault detection |
WO2021047970A1 (en) | 2019-09-10 | 2021-03-18 | Volkswagen Aktiengesellschaft | Software components for a software architecture |
CN112783736A (en) * | 2021-03-01 | 2021-05-11 | 苏州挚途科技有限公司 | Method and device for monitoring running body time of software component and electronic equipment |
CN112783736B (en) * | 2021-03-01 | 2024-04-19 | 苏州挚途科技有限公司 | Method and device for monitoring running body time of software component and electronic equipment |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR20140066531A (en) | A component architecture based on autosar(automotive open system architecture) | |
EP2123517B1 (en) | Vehicle control system | |
Kum et al. | AUTOSAR migration from existing automotive software | |
KR100958303B1 (en) | A System and A Method for Dynamic Loading and Execution of Module Devices using Inter-Core-Communication Channel in Multicore system environment | |
CA2208297C (en) | Method and computer program product for reducing inter-buffer data transfers between separate processing components | |
CN113939805A (en) | Method and system for interprocess communication | |
US20100292867A1 (en) | Motor Vehicle Control Device | |
US9235456B2 (en) | Configuration technique for an electronic control unit with intercommunicating applications | |
JP5967927B2 (en) | Method for bypassing AUTOSAR software elements of an AUTOSAR software system | |
CN114268666A (en) | Universal domain controller, vehicle and interactive system supporting service oriented architecture SOA | |
Bucaioni et al. | Modelling multi-criticality vehicular software systems: evolution of an industrial component model | |
US20220318046A1 (en) | Method, system and domain for providing a security execution environment for security-relevant applications | |
CN114691234B (en) | AUTOSAR-based program configuration method, system, equipment and medium | |
CN113448902A (en) | Processing system, integrated circuit, device and method with queued serial peripheral interface | |
WO2024093731A1 (en) | Automotive open system architecture, data processing method and on-board device | |
KR20170059685A (en) | Apparatus for communicating diagnostic vehicle based on autosar and method thereof | |
CN115412394B (en) | Heterogeneous domain controller inter-core communication method based on AutoSar | |
Gemlau et al. | A new design for data-centric Ethernet communication with tight synchronization requirements for automated vehicles | |
US20080134157A1 (en) | Approach and System for Process Execution of an Integrated Telecom Platform | |
US10958472B2 (en) | Direct access to bus signals in a motor vehicle | |
CN110955602A (en) | Distributed embedded software testing system based on resource sharing | |
CN116126776A (en) | Memory access method and device based on MCAL and multi-core chip | |
CN112445728B (en) | Robot development board ROS communication system supporting multiple hardware interfaces | |
KR102418629B1 (en) | Control method of motor pulse width modulation based on autosar | |
JP2010033436A (en) | Control apparatus, control method, and computer program |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
N231 | Notification of change of applicant | ||
WITN | Withdrawal due to no request for examination |