오늘의 CS 지식은 AUTOSAR 관련 지식이다.
차량 쪽의 지식을 굳이 CS로 정리하는 이유? 그것은 이러한 SW 컴포넌트는 어딜 가던 비슷할 것 같아서..
실제로도 유니티 SW 개발을 하던 당시에도 SW Component를 제작하고 이걸 재활용하는 방안을 최대한 모색했었다.
그렇기에, 순수 SW에서도 쓰이는 개념을 임베디드에서 안 쓸리가 없었고, 이러한 형태는 차량뿐만 아닌 방산, 의료기기 등 여러 분야에 쓰일 가능성이 높다고 생각하여 정리하게 되었다.
[RapidAUTO] AUTOSAR 그것이 알고 싶다 (3) - SW 컴포넌트 개념편
🔗 AUTOSAR 그것이 알고싶다 (1) 프롤로그 🔗 AUTOSAR 그것이 알고싶다 (2) AUTOS...
blog.naver.com
위 블로그에서 참고하여 작성함!! (MDS 인텔리전스라는, AUTOSAR 등 다양한 SW 관련 제식화 회사)
우선 정리하기 전에, 잠시 https://termuni.tistory.com/39
AUTOSAR 기반 프로그램Folder Tree 분석
AUTOSAR란 어떻게 보면 프로토콜, 즉 규약과 비슷하게 생각하면 된다.물론!!! 프로토콜이란 말은 아니다. 이해하기 쉽기 위해 비유를 한 것이니 오해하지 말 것. 이 글을 정리하는 이유는 다름이
termuni.tistory.com
여기에 사진을 보면, 각 네모 안에 작은 네모들이 엄청 많다.
이런 것들을 SW Component(구성요소, 부품)라고 한다고 이해하면 편하며, 이 SW Component들이 층층이 쌓여 만들어진 것이 AUTOSAR의 Layered Architecture라고 이해하면 된다.
이게 적절한 비유일지는 모르겠으나, 사람에 빗대어 비유해보겠다.
사람의 뇌 = RTE
신경 = Interface, 서로 정보를 전달하기 위한 통로
팔 = 하나의 기능
관절 = 컴포넌트
이런식으로 비유를 할 수 있을 것 같다. (틀렸다면 댓글 부탁드립니다.. ㅠ)
어쨌든, 이런 Component를 기반으로 코딩을 하는 것이 오류 발생 확률을 현저히 줄일 수 있기에 잘 만들어서 재활용을 잘 하는 것이 중요하다.
아래는 SW Component 타입의 전체적인 개요이다.
이 SW Component는 총 11가지가 존재한다.
그 중 추상적으로 존재하는 것으로 두개가 있다.
그것은 1, 2번으로, 기울어진 상태로 적혀있다.
그러면 1번부터 차근차근 설명하겠다!
(네이버 블로그 글을 가져온 것을 기반으로 예시를 들고 그 설명을 적으면서 볼 예정이며, 슥 보고 모르겠으면 예제를 보면 더 좋을 것 같다)
1. SwComponentType
: AUTOSAR 문법적으로만 존재하는 추상 meta-class.
: meta-class 간의 상속 개념을 통해 문법을 확장하기 위한 용도일 뿐 우리가 직접 설계할 수 없습니다. (설계하지 않아도 된다는 의미와 같음)
: 즉, 코드로도 생성되지 않습니다.
2. AtomicSwComponentType
: AUTOSAR 문법적으로만 존재하는 추상 meta-class.
: meta-class 간의 상속 개념을 통해 문법을 확장하기 위한 용도일 뿐 우리가 직접 설계할 수 없습니다. (설계하지 않아도 된다는 의미와 같음)
: 즉, 코드로도 생성되지 않습니다.
이 두개 컴포넌트에 대해 설명하자면, AUTOSAR 모델링에 있어 사용되는 개념적 존재이다.
어떻게 보면 거푸집? 이라 생각할 수 있지 않을까? 하는 생각이 든다.
SwComponentType의 예를 들자면 개(Dog), 고양이(Cat), 코끼리(Elephant) 등은 Animal의 하위 개념이지만, Animal 자체는 직접 설계하거나 구현할 수 없는 것과 비슷하다!
AtomicSWComponentType은 AtomicSwComponentType은 '포유류(Mammal)'처럼 좀 더 구체적인 개념으로 보면 된다.
3. ParameterSwComponentType
: AUTOSAR meta-model을 이용하여 직접 설계하는 meta-class.
: 주로 Calibration engineer가 MCD(Measurement, Calibration, Diagnostic) Tool을 사용하여 ECU runtime 시 ECU 내부의 특정 data(calibration parameter)에 대한 특정 Access 목적의 처리를 하기 위한 용도에만 사용되는 특수 목적의 SW 컴포넌트 타입입니다.
(참고) Internal Behavior를 가질 수 없습니다. (나중에 살펴보겠지만, Internal Behavior를 가질 수 없다는 의미는 코드에 상당한 제약이 있다는 의미입니다.)
: "Rte_SW 컴포넌트 이름".h 파일의 코드로 생성됩니다.
정리하면 다음과 같이 이해할 수 있다.
1. 특정 데이터를 받거나, 진단하거나, 교정할 때 사용되는 컴포넌트
2. 일반적인 기능이 아닌, 보정 및 측정용 파라미터 관리가 필요할 때만 사용
3. 운전자(즉, 어플리케이션 사용자)가 직접 제어 할 수 없는 영역이며, 엔지니어(개발자)가 외부에서 데이터 수정 등에 사용되는 요소
4. CompositionSwComponentType
: AUTOSAR meta-model을 이용하여 직접 설계하는 meta-class.
: 주로 Subsystem 1개 당 CompositionSwComponentType을 1개 설계하여 사용합니다.
(즉, Subsytem:CompositionSwComponentType = 1:1 관계)
(참고) Internal Behavior를 가질 수 없습니다.
: 반드시 최소 1개는 설계해야 하지만, 코드로는 생성되지 않습니다.
: 모든 SW 컴포넌트 타입을 통틀어 유일하게 SwConnector를 가질 수 있습니다.
: 모든 SW 컴포넌트 타입을 통틀어 유일하게 다른 SW 컴포넌트 프로토 타입을 가질 수 있습니다.
: SW 컴포넌트들을 계층 구조로 설계할 수 있도록 하기 위한 목적으로 만들어진 컴포넌트 타입이라고 이해하시면 됩니다. (즉, ISO 26262 Part6. SW 아키텍처 디자인 원칙 요구사항 중 "Hierarchical structure of software components"를 만족할 수 있는 기법에 해당)
: 코드로는 생성되지 않습니다.
Composition, 즉 구성을 하는 SW 컴포넌트로, 서브시스템에 1:1로 대응된다.
굳이 그러는 이유는, SW 컴포넌트를 계층 구조로 설계하기 위한 목적이고 , 그래서 Connector가 포함된다.
예를 들어, 자동차의 엔진 제어 시스템(Subsystem)에는 여러 개의 개별 컴포넌트(연료 분사, 공기 흡입, 점화 시스템 등)가 포함된다.
이 아래부터는 하나의 실행 단위로, RTE를 통해 다른 컴포넌트와 통신하는 특징을 가지며, 실행 가능한 Entity가 있을 수 있다.
대강 요약하면 이제부터는 독립적으로 동작한다!
그 이유는 맨 아래에 표로 정리된 것을 올려둘 예정
5. ApplicationSwComponentType
: AUTOSAR meta-model을 이용하여 직접 설계하는 meta-class.
: 하드웨어 의존적이지 않은 순수한 Application로직만을 구현해야 합니다.
: Internal Behavior를 가질 수 있습니다. (나중에 더 살펴보겠지만, Internal Behavior가 있어야 Task Body에서 호출되는 스케줄링 함수인 Runnable Entity를 만들 수 있음)
: "Rte_SW 컴포넌트 이름".h 파일의 코드로 생성됩니다.
하드웨어에 독립적인, 순수 SW 어플리케이션을 동작하게 하는 컴포넌트
ASW쪽이 아닐까? 싶다. 기능안전이나 진단 등.. 관련 동작을 시키기 위한 컴포넌트들!
6. NvBlockSwComponentType
: AUTOSAR meta-model을 이용하여 직접 설계하는 meta-class.
: 주 목적은 비휘발성 메모리 Block에 비휘발성 데이터를 읽고 쓰기 위한 요청을 담당하기 위해 만들어진 특수 목적의 컴포넌트 타입입니다.
(참고) 반드시 비휘발성 메모리에 읽고 쓰기 위한 요청을 NvBlockSwComponentType에서만 처리할 수 있는 것은 아니며, ApplicationSwComponentType으로도 처리 가능
: Internal Behavior를 가질 수 있습니다. (나중에 더 살펴보겠지만, Internal Behavior가 있어야 Task Body에서 호출되는 스케줄링 함수인 Runnable Entity를 만들 수 있음)
: "Rte_SW 컴포넌트 이름".h 파일의 코드로 생성됩니다.
Nv가 붙은 것이 무슨 약자인지 찾아보니, Non Volatile Memory의 그 NV였다. 즉 비휘발성 메모리에 접근하기 위한 Component!
비 휘발성 메모리 하면? 사실 PC로 치면 HDD, SSD와 같은 것을 떠올릴 것이고, ECU와 같은 임베디드 시스템에는 EEPROM이 있다.
7. ComplexDeviceDriverSwComponentType
: AUTOSAR meta-model을 이용하여 직접 설계하는 meta-class.
: 주 목적은 AUTOSAR에서 정의한 MCAL Driver를 사용하지 않고, 자체 개발한 Driver를 사용하여 하드웨어를 제어하기 위한 목적일 때 사용하는 컴포넌트 타입입니다.
: 또한, 마이크로 세컨드 단위(us)로 빠르게 처리해야 하는 로직 등을 구현하고자 할 때 사용하는 컴포넌트 타입입니다.
: Internal Behavior를 가질 수 있습니다. (나중에 더 살펴보겠지만, Internal Behavior가 있어야 Task Body에서 호출되는 스케줄링 함수인 Runnable Entity를 만들 수 있음)
: AUTOSAR에서는 Hybrid SW 컴포넌트 성격을 가진 컴포넌트 타입이라고 부릅니다. (나중에 더 살펴보겠지만, 구현 로직에 따라 BSW Layer에도 존재할 수 있고, ASW Layer에도 존재할 수 있어 Hybrid라고 부름)
: "Rte_SW 컴포넌트 이름".h 파일의 코드로 생성됩니다.
여기서 중요하게 볼 것은 내가 봤을 땐 "마이크로 세컨드(us) 단위로 빠르게 처리"해야 하는 로직을 구현하고자 할 때 사용된다는 것이라고 생각된다.
IVS 교육을 들으면서 기억나는 것 중 하나가 바로 제동장치와 관련된 기능을 만들 때, us 단위로 빠르게 처리해야 할 경우가 있다고 했다.
그래서 그 경우 따로 제작하는 경우가 있다고 하니, 그런 Complex한 것을 만들 때 접근하는 타입이라고 볼 수 있을 것 같다.
8. ServiceSwComponentType
: Configuration Tool을 이용하여 Configuration하면 자동으로 생성되는 meta-class.
: OS, WatchDog, COM과 같은 일부 Basic Software 모듈을 제외한 나머지 Basic Software 모듈이 해당됩니다. (DCM, DEM, NvM, BswM, EcuM 등)
: Internal Behavior를 가질 수 있습니다. (나중에 더 살펴보겠지만, Internal Behavior가 있어야 Task Body에서 호출되는 스케줄링 함수인 Runnable Entity를 만들 수 있음)
: "Rte_모듈 이름 또는 SW 컴포넌트 이름".h 파일의 코드로 생성됩니다.
: "모듈 이름 또는 SW 컴포넌트 이름이 포함된".c 파일의 코드도 생성됩니다.
(참고) 자동 생성되는 .c 구현 파일의 경우 한 개의 .c 파일만 생성될 수도 있고, 여러 개의 .c 파일로 생성될 수 있습니다. (Configuration Tool에 따라 다름. AUTOSAR에서는 .c 파일을 “Implementation-Specific” 이라는 용어를 사용하면서 Tool의 특성/코드 최적화 등을 자유로이 할 수 있도록 강제성을 통한 제약을 하고 있지는 않음을 의미함)
ECU의 기본적인 BSW 모듈이 해당된다고 하며 나와있는 예시가 아주 인상적이었다.
DCM(Diagnostic Communication Manager)은 진단 메세지를 처리하고, DEM(Diagnostic Event Manager)은 ECU 내부 오류를 관리하는 역할을 한다.
이때 NvM을 왜 포함하는걸까? NvBlockSwComponentType과는 어떤 차이일까?
사실 이걸 알아보려고 https://www.autosar.org/fileadmin/standards/R21-11/CP/AUTOSAR_EXP_NVDataHandling.pdf, https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_SWS_MemoryMapping.pdf 등을 봤는데.. 잘 모르겠어서 gpt 물어봤다.
대강 정리하면, ServiceSw컴포넌트는 BSW를 통한 저장 및 관리와 관련된 작업이고, NvBlock은 Application쪽에 좀 더 가까운 영역이라 볼 수 있을 것 같다.
이해를 위해 사진을 잠시 가져와보면
여기의 왼쪽 ㄱ자 모양의 서비스에 8번(ServiceSwComponentType)이 들어가는 것이고, 그 오른쪽의 파란 영역에 6번(NvBlockSwComponentType)이 들어간다고 보면.. 편하지 않을까?
9. EcuAbstractionSwComponentType
: AUTOSAR meta-model을 이용하여 직접 설계하는 meta-class.
: 주 목적은 AUTOSAR에서 정의한 MCAL Driver(ADC, DIO, PWM 등) API(Standarized Interface)를 사용하여 하드웨어를 직접 제어하기 위한 목적(보통 Sensor 값 획득, Actuator 제어 등)일 때 사용하는 컴포넌트 타입입니다.
: Internal Behavior를 가질 수 있습니다. (나중에 더 살펴보겠지만, Internal Behavior가 있어야 Task Body에서 호출되는 스케줄링 함수인 Runnable Entity를 만들 수 있음)
: "Rte_SW 컴포넌트 이름".h 파일의 코드로 생성됩니다.
: (mobilgene AUTOSAR의 경우) .c 구현 파일도 자동으로 생성됩니다.
(참고) mobilgene AUTOSAR의 경우에는 EcuAbstractionSwComponentType 타입을 BSW 모듈로 정의했기 때문에, 직접 설계가 불가능합니다.
ECU Abstraction, 이건 IVS에서 봤다!! 중요한 점으로는 MCAL API를 통한 하드웨어 직접 제어이다.
EBTresos도 그렇고, 모빌진도 그렇고 이 것을 BSW 모듈로 정의했으므로 UI를 통해 간단한 구현이 가능할 것으로 보인다.
10. SensorActuatorSwComponentType
: AUTOSAR meta-model을 이용하여 직접 설계하는 meta-class.
: 주 목적은 EcuAbstractionSwComponetType과 RTE를 통한 통신을 위해 사용하는 컴포넌트 타입입니다.
: Internal Behavior를 가질 수 있습니다. (나중에 더 살펴보겠지만, Internal Behavior가 있어야 Task Body에서 호출되는 스케줄링 함수인 Runnable Entity를 만들 수 있음)
: 하드웨어 Sensor, Actuator와 관련이 있는 SW 컴포넌트 타입이므로 AUTOSAR에서는 어떤 Sensor 또는 어떤 Actuator와 관련이 있는지(HwElement meta-class 설계를 통해) 연관성을 추가로 설계하도록 요구하고 있습니다.
: "Rte_SW 컴포넌트 이름".h 파일의 코드로 생성됩니다.
간단히 얘기하면 센서 또는 액추에이터와 연관된 소프트웨어를 구현할 때 사용된다.
9번과 RTE를 통해 통신하는 HW Interface용 SW 컴포넌트로 이해하면 된다.
좀 더 자세히 이야기 하자면,센서의 데이터를 ASW로 보내기도, 모터와 같은 액추에이터로 정보와 신호를 보내서 동작시키기도 하는, 그런 영역이다.
11. ServiceProxySwComponentType
: Configuration Tool을 이용하여 Configuration하면 자동으로 생성되는 meta-class.
: BswM(Basic Software Mode Manager) 서비스 모듈과 ApplicationSwComponent가 다른 ECU에 Deploy될 때와 같은 특수한 목적일 때 사용되는 컴포넌트 타입입니다.
AUTOSAR에서 특정 서비스(BSW Service)를 다른 ECU에서 사용할 수 있도록 중개(Proxy) 역할을 하는 컴포넌트로, ECU 간에 서로 사용할 수 있도록 해주는 Component로 생각하면 된다.
예를 들어 비상 정지를 해야하는 경우에, 다른 ECU에서 정지 명령을 만들어서 엔진을 관리하는 ECU에 보내야 하므로 필요하다고 볼 수 있다.
여기까지 전체적인 것들에 대한 설명이고, 아래는 요약이다.
계속 정리하면서 궁금해진 것은 "Internal Behavior는 무엇인가?" 였다. 이것이 왜 중요한걸까?
이에 대한 내용은, 혼자 공부하고 만약 공유할만 하다 싶으면 공유할 생각이다. 단, CS 지식이라고 생각 될 경우에만..
그리고 정리하면서 느낀 것은, 안정성을 위해 꽤나 많이 세분화 되어있다는 것이다. 여 쪼개고, 저 쪼개서 구분해놓은 느낌?그리고, 웹쪽으로 갈 수록 필요없는 부분도 꽤 많은 것 같았다. 웹에 대해서 자세히는 모르나, 센서와 같은 내용은 필요 없을 것이기에.. 더욱 그랬다.
하지만, 1, 2, 4, 5, 8과 같은 내용은.. 꽤나 연관성 있지 않았나? 싶기도 하다.1, 2는 오히려 웹에서 추상적이지 않은 형태로 발전했을 것 같고(Class 등으로), 4, 5, 8은 독립원칙 및 사용성 관련해서 연관이 꽤 있을 것 같다.
물론, 내가 전문가도 아니고 잘 모르지만 뇌피셜이기에 연관있어 보인다는 것이다..
아무튼 오늘은 여기까지이며, 다음에는 다른 내용을 정리해보겠다!
'CS 지식 정리' 카테고리의 다른 글
| 함수 포인터란? (0) | 2025.03.14 |
|---|---|
| 스택이란? - C언어 알아보기 (1) | 2025.03.05 |
| 구조체란? - C언어 알아보기 (2) | 2025.02.25 |
| MCU 스케줄링(Scheduling)의 이해 및 TC275 기반 실습 (0) | 2025.02.18 |
| AUTOSAR 기반 프로그램Folder Tree 분석 (0) | 2025.02.16 |