8. Introduction to AUTOSAR

AUTOSAR

• Automotive Open System Architecture
  -> 자동차 산업을 위한 표준화된 소프트웨어 구조
• 자동차 ECU(Electronic Control Unit, 자동차의 다양한 장치를 제어하는 역할)에 내장되는 SW의 표준 체계로서 SW의 표준 구조 및 표준 개발 방법론을 규정하는 체계
• AUTOSAR를 이해한다. = AUTOSAR 플랫폼 위에서 개발하게 되면 만든 프로그램의 구조를 이해하고 그런 프로그램을 어떤 절차로, 어떤 도구를 통해서 만들어야 하는 것을 아는 것이다.
  

Exchangeability and Reuse of SW Components

• Improve flexibility for product modification, upgrade and update
• Improve scalability of solutions within and across product lines
• Improve quality and reliability of E/E systems

AUTOSAR in a Vehicle Network

• 자동차는 기본적으로 Ethernet 프로토콜을 사용하고 무선으로 외부와 연결
• 서버 컴퓨터는 adaptive autosar platform 기반으로 올라가고 그 밑에 자잘한 ECU들은 classic autosar platform으로 만들어진다. 그리고 다른 Non-AUTOSAR platform이 묶여 자동차가 돌아간다.

AUTOSAR Main Architecture

AUTOSAR는 크게 3가지 표준에 대해 정의하고 있다.
1. Architecture
만들어지는 ECU 소프트웨어에 대한 기본 구조를 정의
2. Methodology
소프트웨어를 개발하는 방식 자체를 표준화 시킨 것
3. Application Interfaces

AUTOSAR 기술

• MDE : Model Driven Engineering
  • 분석과 설계를 통해 모델을 잘 만들면 그 모델로부터 코드를 자동 생성
  • well defined practice -> 도구를 사용한다. 개발 도구는 metamodeling과 model tranformation을 기반으로 만들어진다.
  • production, maintenance or operation of software intesive system에서 automate goals(자동화)
    -> model과 meta model(해당 모델을 만드는 규칙)을 사용하여 model transformation 과정을 통해 tool로 programming, SW Development을 자동화할 수 있다.
    
• Metamodeling
  실제 상황을 관찰하고 모델로 추상화한다. 그리고 모델을 만드려면 규칙이 존재하여 그것을 보고 모델을 만든다. Metamodel은 중요한 것을 뽑아서 필터링 한다.
  

AUTOSAR Specification

• AUTOSAR Metamodel, Model, ISOLAR
  Metamodel을 통해 model을 만들 수 있는데 model의 대상이 ECU SW 자동차이다. 자동차 ECU SW를 만드려면 우리가 규정한 metamodel을 통해서 model을 만들어주면 자동화(ISOLAR)를 통해 ECU SW를 만든다. Model의 종류는 여러가지가 있다. VFB, IB, System configuration, ECU configuration 등이 있는데 이런 규칙을 정의한 것을 metamodel이라고 하지 않고 template이라고 한다.

Intra- and Inter-ECU Communication

• AUTOSAR는 ECU들끼리 network로 연결된 구조를 갖는 시스템에 개발하는 목적을 가진다.
• Application Component는 Port를 이용해서만 서로 통신할 수 있다.
• RTE(Run Time Enviroment) : 포트와 포트사이의 통신 자체를 책임 -> IB Model을 보고 자동생성
• BSW : OS kernel과 device driver에 해당, 내부통신이면 RTE가 해결할 수 있지만 그렇지 않을 경우에는 BSW를 통해 가야 한다.

=> applictaion SW-C 처럼 모델링만 해주면 RTE와 BSW는 자동생성된다. 결국 AUTOSAR는 모델링을 할 줄 알아야 한다.

AUTOSAR Architecture

아래 그림의 3개의 ECU -> system : 하나의 ECU나 여러개의 ECU가 통신 network에 의해 연결된 것

1. VFB(Virtual Functional Bus) Model
   몇개의 ECU로 나눠질 것이다. 어떤 network로 연결될 것이다. 이런것을 무시하고 기본적으로 내가 만들고자 하는 시스템의 어떤 기능이 필요하고 어떤 component 단위로 쪼갤 것인지를 결정하는 것이다. SW-C Description은 component의 모양을 설명해주는 모델이다.
   • component 이름을 정의해준다.
   • 어떤 포트가 있어야 할지 정의해준다.
   • 포트 간에 연결은 어떻게 되야 할지 규정한다.
2. IB(Internal Behavior) Modeling
   Component 내부의 기능이 자신의 포트들과 어떤 식으로 연결되는지 기술하는 것이다. 내부의 기능을 정의한다.
   • AUTOSAR SWC-C에 코드가 들어가는 데 코드가 어떤식으로 포트(포트는 AUTOSAR Tool이 IB model을 보고 자동생성)와 연결될 것인지 설명한다.
3. System Constraint Description
   ECU들이 어떤 식으로, 어떤 통신으로 묶이는지 설명한다. 전체 시스템의 구조를 설명해준다. 아래 그림에서 3개의 ECU들이 어떻게 묶이는지
4. ECU Description
   하나하나의 ECU는 어떤 구조로 만들어질 것인가를 정의한다. 어떤 CPU를 쓸 것인지, 어떤 OS, 어떤 하드웨어를 사용할 것인지 등을 설명한다.
5. 위의 4가지의 모델이 Deployment tools에 입력시키면 개발 도구가 실제 ECU에 들어가는 실제 코드가 자동생성된다. Application Component 코드만 빼고(AUTOSAR SW-C). 얘는 개발자가 직접 작성한다.

-> 고치는 작업이 수월하다.

SW Architecture

• AUTOSAR는 SW Architecture를 표준화시켰다.(layered architecture, component architecture로 구분할 수 있다.)

1. Layered 관점

   • layered : Application layer에서 생겨난 함수라면 RTE에 있는 함수를 호출한다. BSW에 있는 함수를 바로 접근할 수 없다.
   • Application Layer : 실질적으로 ECU의 기능들을 가지고 있다. Application이란 ECU 소프트웨어에서 control을 위한 application이다. 무엇을 어떻게 control할지는 시스템마다 달라진다.(엔진, 도어 등등) 그런 control logic을 가지고 있는 layer이다.
   • RTE : Automatic generation
   • BSW(Basic Software) layer : OSEK을 예로 들면 OS+Driver라고 할 수 있다.
     • Services Layer
     • ECU Abstraction Layer
     • Microcontroller Abstraction Layer(MCAL)
     • Complex Drivers
     

2. Layerd 안에서 component 관점

   • 모든 layer는 component들로 구성되어 있다.
   • Application layer에 있는 component는 AUTOSAR Interface라는 방식을 통해 RTE하고만 통신할 수 있다.
   • Service layer에 있는 component도 마찬가지로 RTE가 호출을 해줘야 돌아간다. RTE가 동작시킨다.
   • AUTOSAR에서 규정되는 interface의 종류
     • AUTOSAR Interface : port가 있어야 한다.
     • Standardized Interface : component끼리 direct로 호출할 수 있다. 호출할 수 있는 함수의 종류가 표준화되어 있다.
     • Standardized AUTOSAR Interface : RTE와는 port가 있어야만 통신할 수 있지만 포트 자체가 표준화(standardized)되어 있다.
     

Basic Software Modules(BSW)

General Interfacing Rules

• 빨간색은 허용하지 않는다. 초록색은 허용한다. 노란색은 가능은 하지만 하지 말아라.
  

1. MCAL layer
   • MCU 내부 디바이스에 대한 device driver이다.
   • MCU 하드웨어에 대한 dependency와 관련
   • 상위 layer에서 mcal device driver를 쓰는 interface가 표준화되어 있다. -> independent
   • OS(가장 왼쪽)는 MCU에 독립적일 수 없다.
   • AUTOSAR SW 개발이 가능하냐는 두가지에 의해 결정된다. MCU가 AUTOSAR 표준에 맞는 OS와 MCAL을 지원하는지이다.
     
2. ECU Abstraction layer
   • sensor-interface-MCU-interface-actuator 구조로 만들어진 곳에서 sensor와 MCU는 바뀌지 않았는데 interface만 변동이 생겼을 때 영향을 받는 SW를 모아둔 곳이다.
     
3. Service layer
   • OS, OS관련 service 기능을 모아둔 곳
   • OS가 바뀌면 service layer가 바뀌어야 한다.
   • OS 관련 기능
     • Operating system functionality(ex. OSEK API(ACTIVATETASK))
     • Vehicle network communication and management services -> 통신과 network
     • Memory services(NVRAM management)
     • Diagonstic Services
     • ECU state management
       
4. Complex Driver
   • AUTOSAR는 layer를 쪼개놓고 기능들을 표준화시켜놨다. ECU를 만들다보면 표준화된 기능들만으로는 안된다.(처리 효율(속도)문제, 새로운 기능이 필요할 때) 그럴 때 AUTOSAR 표준과는 무관하게 기능들을 만들어 complex driver안에 넣는다. 그리고 interface만 맞춰준다. 그러면 다른 layer와 잘 연결할 수 있다.
     

AUTOSAR Methodology

• 절차(procedure)을 정의하고 tool을 정의하는 것
• VFB를 만든다. -> IB model을 정의 -> system(여러개의 ECU가 network로 연결) description을 만든다. -> 정의된 system 밑에서 ECU Description -> 앞에서 만든 것을 Tool받아서 코드를 만들어 준다.
• template : VFB, IB Model을 만들기 위해 modeling language를 정의해놓은 것
  
• VFB와 IB model을 만들면(SW-Component Description) model로부터 API가 generation되고 API header file을 가져와서 맞춰 소스코드를 작성해주면 Application component의 소스코드가 된다.
• SW-Component Description, ECU Resource Description, System-Constraint Description model이 만들어지면 Tool이 읽어서 system 전체에 대한 configuration을 생성한다. 또 tool에 의해 ECU Configuration model을 만들수 있다.
• 다 링크하면 실제 ECU에 들어가는 AUTOSAR의 실행파일이 만들어진다.
• 주황색 : 사람이 모델링해야 한다. xml파일로 만들어진다.
  동그라미 : tool이 해주는 역할