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

A component architecture based on autosar(automotive open system architecture) Download PDF

Info

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
Application number
KR1020120133894A
Other languages
Korean (ko)
Inventor
박창환
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to KR1020120133894A priority Critical patent/KR20140066531A/en
Publication of KR20140066531A publication Critical patent/KR20140066531A/en

Links

Images

Classifications

    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60RVEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00Electric 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/02Electric 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/451Execution 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

A component architecture based on an automotive open system architecture (AUTOSAR) according to an embodiment of the present invention includes a plurality of application components, and a first component which includes a plurality of runable linked to the application components and a hub runable to exchange data with the runable. Accordingly, it is possible to reduce loads generated, increase data throughput, and utilize resources efficiently.

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.
KR1020120133894A 2012-11-23 2012-11-23 A component architecture based on autosar(automotive open system architecture) KR20140066531A (en)

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)

* Cited by examiner, † Cited by third party
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

Cited By (9)

* Cited by examiner, † Cited by third party
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