mistralko의 등록된 링크

 mistralko로 등록된 네이버 블로그 포스트 수는 6건입니다.

AUTOSAR 그것이 알고 싶다. - 프롤로그 [내부링크]

AUTOSAR 개발이 어려운 이유? 아니 AUTOSAR가 어려운 이유가 뭘까요? 1. AUTOSAR 개념 자체가 어려워서? 2. AUTOSAR 스펙이 너무 방대해서? 3. AUTOSAR 설계 문법이 어려워서? 4. AUTOSAR Configuration이 어려워서? 5. AUTOSAR를 이해하려고 스펙을 보니 기반이 되는 OSEK, UML, Design Pattern, CBD(Component Based Development) 등의 타 지식들까지도 알아야 되서? 6. AUTOSAR 설계와 Configuration을 통해 자동 생성되는 코드를 확인할 수 없어서? 다수의 AUTOSAR 프로젝트를 컨설팅 해 본 결과, AUTOSAR가 어려운 이유는 위의 1~6번까지의 6가지 이유가 전부 다 해당되었습니다. 한번도 경험해 보지 못한 것을 하게 되니 어렵게 느끼는 것은 너무나 당연한 이치 아닐까? 라는 생각도 들긴 합니다. 다만, 실무자들이 (a) AUTOSAR 설계를 경험하고, (b) Ba

AUTOSAR 그것이 알고 싶다. - SW 컴포넌트 타입의 내부 구조 편 - "RunnableEntity" [내부링크]

이번에는 AUTOSAR가 어려운 이유였던 "3. AUTOSAR 설계 문법이 어려워서?" 를 깨기 위해 SW 컴포넌트 타입의 내부 구조 관련 문법 중 "RunnableEntity"에 대해 살펴보고자 합니다. "RunnableEntity"와 "RTE Event"는 뗄래야 뗄 수 없는 1:1 관계임을 명심해야 합니다. (물론 BSW 일부 모듈의 경우 예외도 있지만...) 즉, "RunnableEntity"만 존재할 수도 없고, "RTE Event"만 존재할 수도 없음을 기억하시길 바랍니다. "RunnableEntity"는 설계하면 코드로 자동 생성됩니다. 어떤 코드일까요? 바로, SW 컴포넌트 파일에 define macro 함수의 형태로 생성됩니다. 좀 더 부연 설명드리면, "RunnableEntity" 함수의 선언 코드가 SW 컴포넌트 헤더 파일에 자동 생성됩니다. 다만, 우리가 흔히 생각하는 일반적인 함수는 아닙니다. 만약, 스레드 함수와 일반 함수를 알고 계시다면 "RunnableE

AUTOSAR 그것이 알고 싶다. - SW 컴포넌트 타입의 내부 구조 편 - "SwcInternalBehavior" [내부링크]

이번에는 AUTOSAR가 어려운 이유였던 "3. AUTOSAR 설계 문법이 어려워서?" 를 깨기 위해 SW 컴포넌트 타입의 내부 구조 관련 문법 중 "SwcInternalBehavior"에 대해 살펴보고자 합니다. 단순히 문법으로만 접근하여 설명하자니 이해가 어려울 듯하여, AUTOSAR meta-model을 사용하여 시각적으로 모델링할 수 있는 AUTOSAR Authoring Tool인 “RapidAUTO”도 함께 활용하여 이해를 돕고자 합니다. 먼저, SW 컴포넌트 타입과 "SwcInternalBehavior" 간의 meta-model 관계를 살펴보겠습니다. 아래 AUTOSAR meta-model 그림과 같이 모든 SW 컴포넌트 타입이 "SwcInternalBehavior"를 가질 수 있는 것은 아닙니다. 좀 더 자세히 설명하면, 아래 그림의 3번(AtomicSWComponentType을 상속한 SW 컴포넌트 타입들) 만 "SwcInternalBehavior"를 가질 수 있으며,

AUTOSAR 그것이 알고 싶다. - SW 컴포넌트 타입의 내부 구조 편 - "PortPrototype" [내부링크]

이번에는 AUTOSAR가 어려운 이유였던 "3. AUTOSAR 설계 문법이 어려워서?" 를 깨기 위해 SW 컴포넌트 타입의 내부 구조 관련 문법 중 "PortPrototype"에 대해 살펴보고자 합니다. 앞서 살펴봤듯이 AUTOSAR는 대부분 타입-프로토타입의 관계로 정의되어 있으며, SW 컴포넌트 또한 SW 컴포넌트 타입과 SW 컴포넌트 프로토타입의 관계로 정의됩니다. (참고) SW 컴포넌트 프로토타입은 SW 컴포넌트 타입의 인스턴스(Instance)를 의미함. SW 컴포넌트 타입을 만들었다면, 반드시 해당 SW 컴포넌트 타입의 인스턴스인 SW 컴포넌트 프로토타입은 최소 1개는 존재해야 하며, SW 컴포넌트 프로토타입이 어떤 SW컴포넌트 타입의 인스턴스인지를 가리키는 Link(연결) 설계가 되어 있어야 합니다. (아래 그림 참고) 간단히 C 언어 코드에 int var1; int var2; 라는 코드가 있다고 가정하면, 타입은 int를 의미하며, 프로토타입은 var1, var2를 의

AUTOSAR 그것이 알고 싶다. - AUTOSAR 개념 편 [내부링크]

이번에는 AUTOSAR가 어려운 이유였던 "1. AUTOSAR 개념 자체가 어려워서?" 를 깨기 위해 AUTOSAR 개념에 대해 살펴보도록 하겠습니다. AUTOSAR는 AUTomotive Open System ARchitecture의 약어로, (SW Architecutre level만 커버) Layered Architecture (계층형 아키텍처)라는 Design Pattern이 적용된 논리적인(물리적이 아닌) 의미의 hierarchy 계층 구조입니다. (참고) Layered Architecture (계층형 아키텍처)는 "특정 계층의 인터페이스가 변경되면 인접 계층만 영향을 주기 위한 특징을 가짐" 보통, AUTOSAR Layer는 Hardware를 기준으로 인접한 하위 Layer부터 상위 Layer 순서로 표현하면 MCAL(AUTOSAR Device Driver Layer), BSW(Basic Software Layer), RTE(Middleware Layer), ASW(Appli

AUTOSAR 그것이 알고 싶다. - SW 컴포넌트 개념 편 [내부링크]

이번에는 AUTOSAR가 어려운 이유였던 "3. AUTOSAR 설계 문법이 어려워서?" 를 깨기 위해 SW 컴포넌트 문법을 살펴보고자 합니다. 먼저, SW 컴포넌트 내부 문법을 살펴보기 전에 AUTOSAR SW 컴포넌트에는 어떤 것들이 있는지 살펴보겠습니다. AUTOSAR meta-model(설계 언어)은 UML 2.0 meta-model을 근간으로 만들어졌으니 AUTOSAR SW 컴포넌트는 UML의 어떤 element에서부터 출발하여 확장/변경했을 것 같은데라는 유추가 가능할 것입니다. 정답은 UML에 정의된 Class의 문법(Syntax)/의미(Semantics) 등을 바탕으로 확장된 것이 AUTOSAR SW 컴포넌트(엄밀히 말하면, SW 컴포넌트 타입)입니다. 그렇다면, UML은 Class-Object(또는 Instance) 구조인데, UML의 Class가 AUTOSAR에서 "SW 컴포넌트 타입"이라면, UML의 Object에 대응되는 것이 AUTOSAR에서는 무엇이 있을까요?