In der Ruhe

AUTOSAR Basic Software(BSW) 개발환경(1)

기록해연 — Wed, 16 Jul 2025 11:28:46 +0900

오토사 개발시 개발툴 사용이 필수.

A: Authoring Tool, B: BSW Configuration Tool

(일반적으로 Authoring Tool, BSW Tool은 같은 회사 제품 사용)

예시

Vector
A: Davinci Developer
B: Davinci Configuration
현대오토에버
Mobilgene (A, B 통합)
ETAS
A: ISONLAR-A
B: ISONLAR-B
EB
B: EB Tresos
DASSAULT SYSTEMS
A: Autosar Builder

AUTOSAR BSW Layer

Service Layer
Ecu Abstraction Layer
MicroController Abstraction Layer (MCAL)
엠칼 영역은 개발툴 회사에서 판매X. MCU제조사들이 제공.

Peripheral (페리펄럴): MCU 내부의 다양한 하드웨어 장치

MCU SW는 MCU 내부의 각종 패리퍼럴을 컨트롤함으로써 실질적으로 동작 가능.

사용하는 MCU마다 SW가 서로 달라 소프트웨어 재사용이 어려움.
→ 이런 문제를 해결하기 위해 AUTOSAR에서 만든 영역이 MCAL.

MCU를 직접적으로 컨트롤하는 부분을 표준화시켜 BSW(MCAL) 영역에 위치.

(원칙적으로 MCU 접근은 BSW MCAL 에서만 가능)

MCU 마다 내부 패리펄럴 구조가 달라 MCAL 소프트웨어 코드는 MCU마다 별도로 개발되어야 함.

MCAL SW는 MCU 제조사에서 본인들의 제품에 맞게 제공(유/무료)

모든 MCU에 대해 지원하지는 않으므로 MCAL 지원하는 MCU 확인 필요.
구현된 MCAL SW는 MCU마다 다르지만, MCAL Configuration Tool은 모두 EB사의 EB Tresos 사용.

CDD(Complex Drivers)

소프트웨어 기능을 구현해야하는데 AUTOSAR에서 표준화가 안되어있는 경우, 기존에 만들어져 있는 AUTOSAR 아키텍쳐를 그대로 활용하기에는 비효율적인 상황이 있을 때 활용하는 영역.

AUTOSAR 개발시 사용되는 Tool

Authoring Tool
- Application Layer
BSW 모듈코드 & BSW Configuration Tool
- Runtime Environment(RTE)
- Services Layer(in BSW)
- ECU Abstraction Layer(in BSW)
MCAL SW 모듈코드 & MCAL Configuration Tool
- MicroController Abstraction Layer(in BSW)

AUTOSAR Basic Software(BSW) 모듈

기록해연 — Tue, 15 Jul 2025 12:39:40 +0900

Basic SW

: 자동차 SW에서 사용하는 여러 제어기들이 공통적으로 사용하는 기능들의 SW 아키텍쳐를 표준화 한 영역

OS
통신
메모리
HW I/O (Dio, PWM, ADC, ICU 등)
와치독

SW 모듈마다 각자 다른 역할을 가지고 있고, 서로 연계되어 동작함.

MCU SW 전체적인 실행 흐름을 총괄.
Task 기반으로 동작
Task Mapping: OS에 태스크를 생성하고 러너블과 매핑하는 작업.
※ BSW Configuration Tool 사용(SWC 영역 설계하는 Authoring Tool과 다른 툴)

통신

메시지 송수신
진단통신(UDS 프로토콜)
XCP(변수 계측, 변수 값 변경 등)
Network Management

HW I/O

MCU 핀을 통해 전기적 신호 생성, 전압 감지 등의 기능을 제공하는 SW표준화(DIO, ADC, PWM 등)

은색 부분이 MCU pin

DIO: Digital Input/Output (DPIO)
ADC: Analogue to Digital Converter. 특정 Pin에 걸려있는 전압을 측정.

Watchdog

: MCU가 비정상적 상태인지 감지해서 MCU를 강제로 Reset

AUTOSAR는 SW모듈마다 각각 아키텍쳐 문서를 오토사 홈페이지에서 무료로 제공.

www.autosar.org
SWS: Software Specification. 아키텍쳐 문서 약어.
ex) 검색시 autosar sws can, autosar sws pdur, autosar sws nvm 이런식으로 검색

표준화된 아키텍쳐만 제공하고 실제 사용가능한 Code는 AUTOSAR에서 제공하지 않음.

→ 오토사 SW 모듈 및 개발 Tool 판매회사에서 BSW SW 모듈 코드를 구현하여 BSW Configuration Tool과 함께 판매함.

ex) EB사의 EB Tresos AutoCore, Vector사의 MICROSAR, 현대오토에버사의 모빌진

AUTOSAR Port(3) - Client Server Inferface

기록해연 — Mon, 14 Jul 2025 17:13:19 +0900

Client Server Interface (C/S)

다른 SWC에 정의된 함수 호출시 사용.

AUTOSAR 개발 방법론에서 외부 SWC에 구현된 함수를 코드 상에서 직접 호출해서 사용하면 X

파라미터 Direction

in : 함수 내부에서 인풋으로 사용
out : 함수 결과값을 담는 용도
inout : 인풋 + 결과값 용도

예시

int Add(int a, int b, int* result)
{
    *result = a+b;
    
    return 0;
}

a, b는 in, result는 out

Direction에 따라

in : 포인터 형태 X
out, inout : 포인터 형태의 코드

CS Port Interface 설계 과정

1. CS Port Interface 만들기

2. Operation 추가

Operation : CS 인터페이스에서 정의하는 함수
포트 인터페이스 설계시에는 함수 형태만 정하고, 함수 내부의 코드 구현은 유저가 별도로 구현.
Operation의 리턴값은 의미있는 결과값 X, 문제가 생겼을 때 외부로 알리기위한 에러코드를 리턴하는 용도로만 제한.
예시

int Add(int a, int b)
{
    return a+b;
}

위의 방식 대신 아래 처럼 작성해야 함.

int Add(int a, int b, int* result) // 결과값을 담기 위한 파라미터 추가
{
    int ret = 0;
    *result = a+b;
    
    return ret;
}

3. Operation 이름 정하기

4. Operation 에서 사용할 파라미터 설정(파라미터명, 데이터타입, Direction)

예시
Name: Command
Data Type: uint8
Direction: In

5. Error Code 설정(필수X)

Application Errors(Possible Errors)에 Error Code 명, Error Code 값(0: 정상 / 1~63 : 사용자가 설정) 추가
- Error Code 사용하는 경우 리턴 타입 StdReturnType (unsigned 8bit 정수형 데이터타입)
- Error Code 사용하지 않은 경우 리턴 타입 Void
Operation에서 사용할 Error Code 선택

6. SWC에 Port Prototype을 추가

Port Prototype의 이름 지정(Port Interface랑 Port Prototype은 별개이므로 따로 지정) - ex. LampPort
Sever: 함수 호출받는 SWC / Provide Port (서비스 제공)
Client: 함수 호출하는 SWC / Require Port (서비스를 제공 받음)

7. RootComposition에 올려두고 Port 간 연결

포트 설계 후

1. SWC에 Runnable 추가

Client가 Operation 호출을 요청했을 때 실행될 서버 Runnable을 SWC에 추가하는 작업을 Authoring Tool로 해줘야 함.

2. Server쪽에 OperationInvokedEvent 등록 및 세팅

Runnable의 이벤트 세팅. (호출 조건 세팅)
서버 포트에 만들어져있는 오퍼레이션과 사용할 러너블 매칭.

3. Client 쪽에 ServerCall Point 세팅

소프트웨어 컴포넌트 간의 연결은 RTE(Runtime Envirenment) 영역이 담당.
→ SWC간의 함수 호출하는 경우에도 RTE가 담당해야함. 러너블을 직접 호출하면 오토사 규칙 위반.
→ RTE API를 호출(RTE API가 러너블 실행)

#include "Rte_SeatBelt.h"

void SeatBelt_MainFunction(void)
{
    uint8 Lamp_Command;
    
    if(조건만족시)
    Rte_Call_LampPort_Lamp_Control(Lamp_Command);
}

각 러너블마다 Call 하려는 Operation의 Server Call Point를 추가
→ 그래야 Operation 호출을 위한 RTE API가 생성됨.
- Synchronos방식: Client SWC에서 함수 호출하는 러너블에 Synchronous ServerCallPoint 세팅
- Asynchronos방식: Client SWC에서 함수 호출하는 러너블에 Asynchronous ServerCallPoint 세팅

※ 설계한 결과물은 모두 Arxml 형태로 작성됨.

4. 설계 내용 Code Generation

5. 러너블 내부코드 구현 및 생성된 RTE API 활용

RTE API 네이밍룰

: Rte_Call_포트프로토타입명_오퍼레이션명

예시

포트 인터페이스명: Pi_LampControl
오퍼레이션명: Lamp_Control
클라이언트 SWC의 Port Prototype명: LampPort

//Rte_Call_포트프로토타입명_오퍼레이션명
Rte_Call_LampPort_Lamp_Control

Synchronous Call VS Asynchronous Call

- 특이사항이 없다면 Sync방식 이용

Synchronous 방식 (Blocking)

: 함수 호출시 곧바로 실행.

Operation Call
Operation Code 실행
나머지 코드 실행

Asynchronous 방식 (Non Blocking)

: 함수 실행 요청만 보낸 상태로 하던 작업 계속 수행. 서버 러너블(오퍼레이션)은 나중에 실행.

(오퍼레이션 실행시간이 오래 걸리는 경우 사용)

Operation Call
: OS에게 Operation 실행 요청
나머지 코드 실행
OS에 의해 나중에 Operation 실행
Rte_Result API : Operation 실행 결과를 받기 위한 추가 API 사용.
ㄴ아직 실행되지 않아 결과값이 담겨있지않아서 따로 받아와야함.
(결과값 전달 받을 러너블에 AsynchronousServerCallResultPoint 세팅해줘야 Rte_result API 사용 가능)

Rte_Call_TestPort_Add(data1, data2, &result);

위를 아래처럼 나누어 사용.

Rte_Call_TestPort_Add(data1, data2);

Rte_Result_TestPort_Add(&result);

Rte_Result API의 Return 값:

// Operation 수행 완료된 경우
#define RTE_E_OK       (0)  

// Operation 수행 안끝난 경우
#define RTE_E_NO_DATA  (131)

Operation 실행 완료 여부를 알림받고 싶다면 AsynchronousServerCallReturnEvent를 활용.

요청한 Operation 실행 결과를 받기 위한 2가지 방식

Polling 방식

: RTE_Result API 호출시 오퍼레이션이 아직 완료 안되었다면, RTE_E_NO_DATA 리턴하여 알려주고 끝남. 결과 받으려면 나중에 다시 RTE_Result 호출해야 함.

Waiting 방식

: RTE_Result API 호출시 오퍼레이션이 아직 완료 안되었다면, 뒤쪽 코드가 먼저 실행되는게 아니라 오퍼레이션이 완료될 때까지 기다렸다가 뒤의 코드 실행.

Waiting Point 설정 필요.

RTE Return Event

Async 방식을 이용하여 오퍼레이션 호출시, 나중에 서버에서 오퍼레이션 실행이 완료되면 클라이언트의 특정 러너블을 실행시키는 동작 방식. (Polling 타입에서만 사용 가능)

AUTOSAR Port(2) - Sender Receiver Inferface

기록해연 — Thu, 10 Jul 2025 17:11:42 +0900

Sender Receiver Inferface

Data Element : Sender Receiver 포트를 통해 주고받는 정보를 데이터.

Data Element와 별개로 Port Interface를 하나 설계했으면 해당 Port Interface의 이름도 별도로 지정해야 함.

포트 인터페이스 만드는 단계에서는 어떤 정보를 주고받을 지에 대한 설계,

P Port (Provide Port) : 데이터를 보내는 쪽의 Port Prototype

R Port (Require Port) : 데이터를 받는 쪽의 Port Prototype

※ P포트용 인터페이스, R포트용 인터페이스가 따로 있는게 아니고, 동일한 포트 인터페이스를 사용해서 소프트웨어 컴포넌트에 포트를 추가하는데 그 포트가 연결되는 소프트웨어 컴포넌트의 역할에 따라 P포트, R포트라고 지정해서 Port Prototype을 만드는 것.

Sender(P Port) → Receiver(R Port)는 1:N 연결 가능(N:1은 불가능)

포트와 포트를 연결하는 작업은 SWC Type상태에서 X.

컴포지션의 SWC를 Prototype으로 만들어놓고 컴포지션 상에서 연결.

Sender Receiver Inferface 설계 과정

1. 포트 설계
S/R 포트 인터페이스를 만들고 이름을 지정.

- 해당 포트로 주고받을 데이터 엘리먼트 설계.

- 엘리먼트의 이름을 정하고, 데이터 타입을 정함.

BeltStatePort 
- Belt_State : uint32

BeltStatePort → 포트 인터페이스 이름
Belt_State → 엘리먼트 이름
uint32 → 데이터 타입

2. SWC에 포트 추가

포트 인터페이스를 사용하여 SWC에 Port Prototype 생성.
(Sender SWC에는 P Port, Receiver SWC에는 R Port 생성)

3. 컴포지션 상에서 P port 와 R Port를 연결.

4. Runnable 추가

툴의 Code Generation 기능을 이용하여 실제 C코드 구현

5. 컴포넌트에 정의된 Runnable마다 해당 Runnable이 실제로 포트를 통해 정보를 주고 받을지(Variable Access) 세팅.

해당 세팅을 해줘야 실제 정보를 주고받기 위한 RTE API Code를 툴이 생성해줌.
SWC에 포트를 추가하고 컴포지션 상의 포트연결까지 했더라도 Variable Access가 세팅되어 있지 않다면, 이 포트를 사용하는 Runnable 이 없다고 판단해 RTE API Code를 생성하지 않음.
세팅방법
툴을 사용하여 각 Runnable 별로 사용하려는 Port의 데이터 엘리먼트에 대한 Variable Access를 이 Runnable에 세팅.(정확히는 포트별로 세팅하는게 아니라 데이터 엘리먼트 별로 세팅)
- [Explicit] Variable Access를 Sender에서는 Data Send Point, Recei ver에서는 Data Receive Point 라고 지칭.
- [Implicit] Variable Access를 Sender에서는 Data Write Access, Recei ver에서는 Data Read Access 라고 지칭.

※ 설계한 결과물은 모두 arxml형태.

사용방식: Explicit 방식 VS Implicit 방식

21강 교육자료 참조

파일명: 04_03_Port - Sender Receiver Port - 보충( Implicit & Explicit)_워터마크.pdf

Explicit 방식

SWC간에 주고 받을 데이터가 RTE변수로 선언되고 RTE Write API 호출시 곧바로 RTE 변수값이 업데이트, RTE Read API 호출시 현재RTE 변수에 쓰여있는 값(최신값)을 읽어가는 방식.

// 네이밍
Rte_Write_BeltState_Belt_State(1); // Explicit Write 
//Rte_Write_포트프로토타입명_데이터엘리먼트명

Rte_Read_BeltState_Belt_State($read_data); // Explicit Read
//Rte_Read_포트프로토타입명_데이터엘리먼트명

Implicit 방식

(OS Task 스케줄 정책에 의해 특정 러너블 실행 도중, 다른 러너블이 중간에 먼저 실행되는 경우) 여러 데이터를 주고 받을 때, 데이터들의 일관성을 보장 받기 위해 사용.

정보를 주고 받기 위한 RTE 변수 외에 추가로 버퍼 하나 더 추가.

#include "Rte_Type.h"

unit3 Rte_OutBuffer; // Implicit Write를 위한 버퍼

unit3 Rte_SeatBeltState_Data; // RTE변수. 러너블 종료 후 버퍼값 반영

unit3 Rte_InBuffer; // Implicit Read를 위한 버퍼

Implicit Write

RTE API 호출시 Write 요청값이 버퍼에 담겨있다가 러너블이 종료된 후 RTE데이터에 반영.

// 네이밍
Rte_IWrite_Seatbelt_MainFunction_BeltState_data(1); // Implicit Write
// Rte_IWrite_러너블명_포트프로토타입명_데이터엘리먼트명

Rte_IRead_Cluster_MainFunction_BeltState_data(&read_data);
// Rte_IRead_러너블명_포트프로토타입명_데이터엘리먼트명

Implicit Read

RTE API를 호출하는 러너블이 실행되기 직전에 RTE 변수에 담겨있는 값을 버퍼로 옮겨놓고, 러너블 내부에서 RTE API를 호출했을 때 RTE 변수에 쓰여있는 최신값 대신 미리 옮겨둔 버퍼 값을 읽어감.

AUTOSAR Port(1)

기록해연 — Thu, 10 Jul 2025 14:24:24 +0900

Port Interface

: SWC에 포트를 추가하기 전 포트 설계시 만들어진 결과물 (≈ 설계도)

Port Prototype

: 포트 인터페이스를 실제로 사용할 때 SWC에 추가해서 사용한 포트 (≈ 설계로 지은 건물)

※포트를 서로 연결하는 작업은 컴포지션에 SWC Prototype을 만든 후 가능.

Connector

: 컴포지션 상에서 포트를 서로 연결해 놓은 것.

1. Port Interface 설계

2. SWC Type 설계

SWC Type에 Runnable 생성
SWC Type에 Port Interface를 사용해서 Port Prototype 추가

3. 완성된 SCW Type을 사용해 RootComposition에 SWC Prototype 만들기

4. Composition 상에서 Port들을 서로 연결

Port Interface는 용도에 따라 총 6가지 종류가 있음.

Sender Receiver Inferface (S/R Interface)
: SWC간의 어떤 값을 주고받아야 할 때 사용.
Client Server Interface (C/S Interface)
: 다른 SWC에 정의된 함수 호출할 때 사용.
Nv Data Interface
Mode Switch Interface
Parameter Interface
Trigger Interface

AUTOSAR Software Architeture

기록해연 — Thu, 10 Jul 2025 10:10:02 +0900

https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf

이미지는 위의 링크 참조

ASW(Application SW) : OEM이나 부품사 고유 핵심기능 구현 부분.
- 제품을 컨트롤하기 위한 실질적 로직 구현 영역.
- 하드웨어로부터 독립적(MCU가 바껴도 재사용 가능).
- Software Component(SWC) 로 구성됨.
  - SWC가 포함해야 하는 정보:
    SWC명, Runnable(소프트웨어 컴포넌트 내부에 정의된 함수. 하나의 SWC안에 여러 개의 러너블 추가 가능), Port(외부와 소통하기 위한 인터페이스 등)
    → 이런 내용들이 전부 arxml 형태로 정의.
RTE : ASW와 BSW를 연결하기 위한 영역(직접구현X, Tool에서 코드 제너레이션으로 제공).
BSW : 여러 제어기들이 공통적으로 사용하는 기능 표준화해서 모아둔 영역.
- 하드웨어에 의존적인 부분을 담당하여 Application SW를 하드웨어에서 분리.

SWC 개발

1. SWC 생성(+ Runnable 설계)

2. Port 생성

3. 상호작용이 필요한 다른 SWC 또는 BSW 영역을 포트를 통해 연결

=> Autosar Authoring Tool 로 작업. 작업산출물은 arxml 파일.

Authoring Tool : App SWC, Port, Port 연결 등을 설계하는 툴
BSW Configuration Tool : BSW 영역을 작업하는 툴

Runnable

: SWC의 동작을 정의하는 함수(유저가 SWC를 통해서 구현하려는 기능을 러너블 내부에 구현해서 사용)

1. 러너블 추가

Runnable 속은 비어있으므로 내부코드 구현은 개발자가 직접 해야 함.

2. 이벤트 세팅 (러너블이 호출될 조건)

러너블 내부의 기능 구현은 사용자가 하지만, 러너블을 호출하는 코드를 사용자가 직접 구현X(툴을 통해 생성된 RTE코드와 OS에 의해 구현되기 때문)
→ Authoring 툴로 러너블 설계시 각 러너블이 실행될 조건도 설계 필요(Event)
ex) Init, Timing, Data Recevied, AsynchronousServerCallReturnsEvent 등

3. OS Task 생성 및 기타 설정

OS모듈: 러너블들을 호출해서 소프트웨어 실행을 전체적으로 통제하는 역할

4. Task 매핑

Runnable에 이벤트를 세팅된 이벤트들을 OS와 연결해주는 Configuration(설정) 작업을 추가로 해줘야 함.
※ OS는 BSW 모듈이라 Authoring툴이 아니라 BSW Configuration 툴을 이용해야 함.

Port

: 외부의 SWC와 소통하기 위한 통로 역할 (AUTOSAR에서는 포트를 통해서만 다른 SWC와 소통하도록 정의되어 있음)

→ 포트를 만드어서 Code Generation시 RTE API가 생성.

1. 포트 설계

포트에 대한 각종 세부사항 설계

2. SWC에 포트 추가

3. 컴포지션 상에서 포트 연결

컴포넌트들을 컴포지션에 올려두고 컴포지션 상에서 포트 연결.

SWC Type

: 아직 컴포지션 상에 올라가지 않은 상태의 SWC.(≈건물 설계도)

SWC ProtoType

: 실제로 SWC를 프로젝트에서 사용하기 위해 컴포지션 상에 올려놓은 SWC. (≈설계도를 이용해 지은 건물)

※ SWC Type의 내용이 변경되면, SWC Prototype에도 자동으로 적용.

CAN통신, LIN통신, DBC, LDF

기록해연 — Wed, 9 Jul 2025 10:32:56 +0900

✅ 1. CAN 통신 (Controller Area Network)

자동차의 핵심 제어용 통신 – 빠르고 신뢰성 높은 다목적 네트워크

특징 요약

항목	설명
개발	BOSCH사 (1980년대)
속도	최대 1Mbps 이상 (CAN FD는 더 빠름)
구조	멀티마스터, 버스형
사용 위치	엔진제어, 브레이크, 에어백, 변속기 등 핵심 제어
장점	고속, 충돌 방지(우선순위), 내구성 강함
단점	복잡한 구조, 비용 높음

예

엔진 컨트롤러가 휠속도, 브레이크 상태, 변속기 정보를 실시간으로 주고받음

✅ 2. LIN 통신 (Local Interconnect Network)

비교적 단순하고 저속·저비용 통신 방식 – 보조 시스템용

특징 요약

항목	설명
개발	LIN Consortium (2000년경)
속도	최대 20kbps (CAN보다 훨씬 느림)
구조	싱글 마스터–멀티 슬레이브 구조
사용 위치	창문, 시트 조절, 실내조명, 거울 제어 등 비핵심 기능
장점	간단함, 저비용, 배선 수 절약
단점	느린 속도, 신뢰성은 CAN보다 낮음

예

조수석 창문 스위치를 누르면 LIN 통신으로 슬레이브 노드가 유리를 올림

⚖️ CAN vs LIN 비교 정리

항목	CAN 통신	LIN 통신
사용처	엔진, 변속기, 브레이크 등 핵심 제어	창문, 시트, 조명 등 보조 제어
통신속도	최대 1Mbps 이상	최대 20kbps
통신구조	멀티마스터 (버스형)	마스터-슬레이브 (직선형)
비용	상대적으로 고가	저가
신뢰성	매우 높음	비교적 낮음
배선	약간 복잡	단순

비유

CAN = 고속도로 (빠르고 정밀, 핵심 부품용)
LIN = 골목길 (천천히 가도 되는 기능에 적합)

(AUTOSAR 실무에서 언급되는) DBC 파일과 LDF 파일은 자동차 네트워크 통신 정의 파일. 각각의 파일은 다른 프로토콜에 해당하고, AUTOSAR 툴에서 통신 설정 자동화에 꼭 필요함.

✅ 1. DBC 파일이란?

CAN 통신용 데이터베이스 파일 (CAN Database File)

주요 내용

CAN 통신 메시지와 신호(Signal) 정의
송신/수신 노드, 메시지 ID, 주기, 데이터 길이, 스케일 정보 포함
.dbc 확장자
Vector사의 CANdb++ 형식이 대표적

구성 예

BO_ 123 ABS_Info: 8 ABS
 SG_ WheelSpeed : 0|16@1+ (0.01,0) [0|300] "km/h"  ECU1

→ "ABS_Info"라는 메시지 ID 123에 "WheelSpeed"라는 신호가 정의됨

✅ 2. LDF 파일이란?

LIN 통신용 설명 파일 (LIN Description File)

주요 내용

LIN 통신 프레임/신호/스케줄 정의
Master/Slave 노드 정보 포함
.ldf 확장자
LIN Consortium 표준 형식

구성 예

Node {
   Master: Master1;
   Slaves: Slave1, Slave2;
}
Frame {
   name: EngineData;
   id: 0x20;
   publisher: Master1;
   signals: RPM;
}

→ Master 노드가 "EngineData"라는 프레임을 0x20 ID로 송신

✅ DBC vs LDF 요약 비교

항목	DBC 파일	LDF 파일
통신 방식	CAN	LIN
파일 확장자	.dbc	.ldf
용도	CAN 메시지/신호 정의	LIN 프레임/신호/스케줄 정의
주요 제작	Vector CANdb++ 등	LIN Configuration Tool 등

✅ AUTOSAR 실무에서의 활용

AUTOSAR 툴(Elektrobit, Vector DaVinci 등)에 DBC/LDF를 Import해서
→ 자동으로 COM 설정 (PDUs, Signals, ECU Mapping 등)을 생성함

MCU, Micro Controller Unit (마이크로 컨트롤러 유닛)

기록해연 — Wed, 9 Jul 2025 09:50:31 +0900

인프런에서 AUTOSAR 강의를 듣기 시작했는데 MCU가 정확히 무슨 뜻인지 모르겠어서 정리해봄.

✅ MCU의 뜻 (자동차 SW 개발 맥락에서)

MCU = Micro Controller Unit (마이크로컨트롤러 유닛)

즉, MCU는 작은 컴퓨터 역할을 하는 칩으로, 자동차의 다양한 전자 제어 시스템(ECU) 안에 들어가 있음.

ECU

ECU 위의 저 큰 검정 판이 MCU(작은 크기의 컴퓨터)

✅ 자동차에서 MCU가 쓰이는 예

AUTOSAR에서는 보통 아래와 같은 제어 소프트웨어의 기반 하드웨어가 MCU.

제어 대상	MCU 역할
전기차 구동모터	모터 제어 및 속도 조절
BMS (Battery Management System)	배터리 잔량, 온도, 충전 상태 모니터링
충전기 (OBC/LDC)	충전 전류·전압 제어
에어백, 조향장치 등	센서 입력에 따른 빠른 제어 수행

✅ AUTOSAR와 MCU의 관계

AUTOSAR는 자동차 소프트웨어의 표준 아키텍처
이 소프트웨어는 MCU(하드웨어) 위에서 실행됨
AUTOSAR를 적용하면 다양한 MCU에서도 호환 가능한 소프트웨어 개발이 가능

요약

용어	뜻	설명
MCU	Micro Controller Unit	자동차 부품(ECU) 안에서 동작하는 소형 컴퓨터 칩
AUTOSAR	Automotive Open System Architecture	자동차 SW를 표준화하는 플랫폼 구조
관계	AUTOSAR 기반 SW는 MCU 위에서 동작함

2025 상반기 회고

기록해연 — Wed, 2 Jul 2025 16:34:37 +0900

2025년도 어느새 반이 지났다.
사실 올해는 회고를 좀더 주기적으로 써보려했는데, 각종 일들이 꼬이면서 이렇게 상반기 회고로 기록하게 되었다.

지난해 12월 나는 현재의 회사로 이직하였다.
기존에 1월부터 투입되기로했던 큰 프로젝트가 무산되면서 강제로 일을 쉬게되었다. 처음에는 그냥 조금 시기가 밀린 것으로 생각되어 크게 신경쓰지 않았으나 몇차례 시작이 밀리며 문제의 심각성을 뒤늦게 받아드리게 되었다.

물론 일이 없다고해서 무작정 논 것은 아니었고, 몇달간 Outsystems 교육도 받고 시험에도 도전했으나 아쉽게 한 문제 차이로 떨어졌다. 공부는 꽤 해서 나름 자신 있었는데, 시험이 영어로 되어있다보니 오역으로 인해 그렇게 된 거 같다는 생각도 들었다. 시험비가 비싸고, 상황이 불확실해서 재시도는 우선은 미뤄뒀다.

3월부터 5월, 약 3달간 주 2회씩 다낭의 직원들에게 한국어를 가르치는 봉사 프로그램에 참여했다.

수업은 온라인으로 진행되었고, 다행이도 어느정도 한국어가 되는 분들이라 수업은 한국어로 무리없이 진행되었다. 누군가를 가르친다는 것은 항상 생각보다 폼이 많이들고, 스스로도 그 준비과정에 있어 꽤나 많은 공부가 필요한 것이라는 것을 이번에도 깨닫게 되었다.

중간에는 이걸 왜 한다고 했을까 후회도 잠깐 한 적이 있고, 가끔은 관성에 젖어 기계적으로 준비한 적도 있으나 그래도 꽤나 보람차게 진행했던 것 같다. 아쉬운 점은 온라인이다보니 조금 제한적인 커뮤니케이션과 직접 교감할 수 없다는 점 정도였다. 쓰다보니 맡았던 반 학생동료(?)분들이 보고싶다.

수업중 팀즈 녹화 캡쳐

+ 당시에 예습자료로 준비했던 노션자료 (수업자료는 따로 ppt로 준비했었음)
https://proyen.notion.site/Korean-Class-Danang-T3-T5-6203c2171c9849bba7823cbe844cd5dc?source=copy_link

5월에는 팀원들과 함께 팀에서 써볼만한 웹페이지를 만들어보기로 했는데 갑작스러운 팀원 변경 등 여러문제가 있어서 순조롭지는 못했다.

우리는 Figma, Erd Cloud 등의 툴의 도움을 받았고, 회의는 팀즈로 진행했다.
뭐로 개발할지 고민했는데 SI 프로젝트에서 주로 만날 수 있는 Java와 Spring Boot, Thymeleaf를 이용한 웹 개발로 진행했다.

나는 기본 화면 틀을 만들고, 투표 게시판을 만들었는데 간단히 이미지도 첨부할 수 있게 만들었다. 백엔드는 딱히 기억에 남는 건 없었고, 화면 CSS 따위에서 고전하며 비교적 시간을 많이 썼다.

아래는 다 만들고나서 진행했던 Demo 시연 팀즈 녹화본 캡쳐.
녹화된 영상은 사실 캡쳐하면서 처음 봤는데 라이브 캡션이 제법 잘 인식되어있어서 조금 신기.

발표는 영어로 진행했고, 각자 자기가 맡은 부분 스크립트를 따로 준비했었다.
영어로 내가 개발한 것을 설명하는 게 처음이라 조금 긴장되었으나 미리 준비해둔 스크립트와 함께라 어찌저찌 해내었다. ~~만약 스크립트를 못보는 상황이었다면 정말 어렵지 않았을까 싶다.~~

그리고 6월, 시간을 그냥 죽이고 싶지 않아서 뭐라도 만들어보자는 생각에 [KBO 구장별 날씨 예보 어플]을 만들었다.

그 유명한 AI를 이용한 '바이브코딩'이란 걸 해봤는데 생각보다 꽤나 매끄럽게 진행되었다. 작년까지만해도 only 폐쇄망에서만 개발을 해왔기 때문에 AI를 이용해서 개발하는게 내게는 익숙치 않은 일이었는데, 생각보다 꽤 많은 도움이 되고 매끄럽게 진행됐다. AI를 어르고 달래서(?) 일하는게 나와 잘 맞는듯하다.

최대한 직관적이고 단순한 UI를 사용했다.

추후 현재 위치받아서 우선 출력해주는 기능도 추가했다.

배포 경험이 별로 없어서 실제로 남들이 직접 사용할 수 있게 vercel과 railway를 이용해서 배포/운영도 해봤다.
안드로이드는 capacitor 로 감싸서 apk 파일로 만들어 설치도 했다. 아이폰은 작업할 수 있는 맥 기기가 없어서 PWA (Progressive Web App)를 이용. 혹은 웹사이트로 이용하게 했다.

아래는 실운영중인 사이트.
https://kbo-ballpark-weather.vercel.app/

Ballpark Weather

kbo-ballpark-weather.vercel.app

아래는 리드미를 포함한 깃허브.
https://github.com/yennie37/kbo-ballpark-weather/tree/main

GitHub - yennie37/kbo-ballpark-weather: KBO Ballpark Weather Application

KBO Ballpark Weather Application. Contribute to yennie37/kbo-ballpark-weather development by creating an account on GitHub.

github.com

도움을 준 테스터들은 주변 야구덕후 친구/지인들, 그리고 나.
사실 테스트랄만한게 없는 사이트라 약간 민망하다.
사소한 오류같은건 친구들에게 보내기 전에 다 잡아뒀던 상황이라 따로 문제가 있거나 불편하다고 들어온 건 없었다. 괜히 섭섭(?).

사실 나는 어플로 깔아두고 거의 매일 들어가 날씨를 확인한다. 지역별로 따로 검색을 안해도되니 제법 유용하다. 나만의 맞춤 어플이랄까 ㅎㅎ.

근데 Trial plan이 이 회고를 쓰고있는 오늘자로 끝나버려서 운영은 한동안 종료할 듯 싶다. 조금 아쉽다.

개발 외의 영역에 대해 말해보자면, 퇴근 후엔 영어와 재봉을 배우러 다니고 있다.

영어는 말할 기회가 너무 없어서 문제인가 싶어 컬컴을 다니고 있다. 늘고 있는지는 모르겠는데 적어도 지금보다 줄지는 않겠거니 생각하며 다니는 중. 이번에 요일을 바꿨는데 새로 만나게 된 리더분이 엄청 댕댕이 같으시다. 여기서 더 많은 시너지 얻고 갈 수 있기를. 언젠간 프리토킹반에 갈 실력이 되려나...?

재봉은 홑겹 하의만드는 과정인데 생각보다 몸이 꽤 고되다. 특히 눈이. 하루라도 어릴 때 배웠으면 좋았을 것을 이라는 생각을 계속하게 된다. 이것들을 이후에 혼자 해낼 수 있을지 정말 미지수. 재봉으로 먹고사시는 분들 진짜 대단하다는 생각만이 든다.
처음에는 시원한 재질의 파자마 바지를 만들었고, 지금은 A라인 스커트를 만들고 있다. 잘하면 이번주에 완성할지도.

그리고 올해 들어 글을 읽는 게 다시 재밌어져서 꽤나 책을 많이 읽었다. 웹소설부터 일반문학, 에세이, 기사, 비문학 등 장르도 가리지 않고 마구잡이로 읽었다. 차근차근 기록해뒀으면 좋았을텐데 라는 생각도 들지만 그러기엔 너무 많이 건너왔나 싶기도.

최근에는 [개발자를 위한 IT 영어 온보딩 가이드] 라는 책을 샀는데, 엄청 실무성 영어라 좋은데 꺼려지고 막 그렇다.

여전히 회사도 갈피가 안잡힌 상황에 집 계약까지 문제가 생겨서 거주/고용 불안정을 동시에 느끼고 있는데, 이제는 그냥 운명이 이끄는 대로 흘러가는 대로 가는 수 밖에는 방법이 없을 거 같아서 최대한 신경쓰지 않으려고 하고 있다.
'집은 정 안되면 그냥 모든 것을 정리하고 쉐어든 고시원이든 들어가지뭐.', '회사는 정규직 전환 안되면 그 기회에 회사 다니며 못해봤던거 해보고 살면 좋지 뭐.', '커리어는 다시 쌓으면 되지 뭐.', 근데 이렇게 생각하면서도 종종 심란해서 잠이 안온다. 빨리 해결되기만을 빌어본다.

반년을 허송세월 보냈다고 생각했는데 또 적다보니 생각보다 많은 것을 하기는 했다. 이제는 또 무엇을 해볼까. 나는 어디로 가게되려나. 정말 인생 앞을 한치도 알 수가 없다. 그래도 되도록 긍정적으로 생각해보려고 노력중.

- 상반기 한줄: 탈서울하기 진짜 힘들다.

map(), 전개연산자 ...

기록해연 — Wed, 2 Jul 2025 11:17:07 +0900

백엔드 속이는 프론트엔드 성능 최적화, ‘Optimistic UI’ | 요즘IT

구글의 'INP(Interaction to Next Paint)' 지표는 사용자 인터랙션 후 화면 업데이트 속도를 측정합니다. 2024년 3월부터 구글은 INP를 Core Web Vitals의 공식 지표로 채택했습니다. 'Optimistic UI' 패턴은 이 INP 지

yozm.wishket.com

위의 요즘레터 보다가 그냥 정리해봄.

글 내용과는 상관없음. 소스만 참조.

.map() 함수

.map()은 배열에서 각 요소를 순회하면서 변형한 새 배열을 만드는 함수.

예시

const numbers = [1, 2, 3];
const doubled = numbers.map(num => num * 2);

console.log(doubled); // [2, 4, 6]

numbers.map(...)는 배열의 각 요소에 * 2를 적용
원본 배열은 그대로 있고, 새 배열을 반환

구조

const newArray = oldArray.map((item, index) => {
  return 변경할값;
});

언제 사용?

목록 데이터 UI로 출력할 때
리스트 항목 수정할 때 (특정 요소만 바꿀 때)
배열을 변형하고 싶은 모든 경우

Spread Operator 전개 연산자 (...)

...은 객체나 배열을 펼쳐서 복사하거나 합칠 때 사용.

in 배열

const arr1 = [1, 2];
const arr2 = [...arr1, 3, 4]; // [1, 2, 3, 4]

arr1을 펼쳐서 [1, 2, 3, 4] 새 배열을 만듦

in 객체

const obj1 = { name: 'Yeon', age: 26 };
const obj2 = { ...obj1, age: 31 };

console.log(obj2); // { name: 'Yeon', age: 31 }

obj1을 복사해서 새 객체를 만들고, age만 덮어씀

왜 필요할까?

불변성 유지를 위해. React에서는 상태를 직접 바꾸지 않고, 새 객체/배열을 만들어 교체해야 함.

const newTodo = { ...oldTodo, completed: true };

이렇게 하면 원본 oldTodo는 그대로 있고, completed만 바뀐 새 객체가 생긴다.

Todo 예제 코드(맨위 링크) 일부

setTodos(prevTodos =>
  prevTodos.map(todo =>
    todo.id === tempId
      ? { ...response.data, isTemporary: false }  // 서버 응답으로 대체
      : todo
  )
);

todo.id와 tempId가 같은 경우 todo에 서버 응답 대체.
response.data는 서버에서 온 객체.
...response.data → 기존 속성 펼치기
isTemporary: false → 거기에 덮어쓰기

+ ❓ 왜 React에서는 상태를 직접 바꾸지 않고, 새 객체/배열을 만들어 교체해야 할까?

React는 "값이 바뀌었는지"를 "겉보기로" 판단하기 때문.

React는 컴포넌트 상태가 변경되었는지 판단할 때 참조(주소)가 바뀌었는지를 확인한다.

예시

const [user, setUser] = useState({ name: 'Yeon' });

상태를 직접 바꾸면(틀린 방법),

user.name = 'Lee';  // 이렇게 하면 내부 값은 바뀌지만
setUser(user);      // 이걸 해도 React는 "어? 참조는 그대로네?" → 변경된 걸 모름

이건 React 입장에서 user === user → true니까, "변화 없음"으로 착각함.

새 객체로 교체시(올바른 방법),

setUser({ ...user, name: 'Lee' });

...user로 기존 값 복사
name: 'Lee'로 새로운 값 덮어쓰기
이건 새로운 객체이기 때문에 user !== 새객체 → React가 "변화 있음" 으로 인식함.

React의 렌더링 조건

React는 상태(state)나 props가 바뀌었을 때만 렌더링을 다시 하고, "바뀌었는지" 판단할 때 값이 아니라 주소(참조)를 비교한다.

직접변경	새 객체로 교체
obj.key = val	setState({ ...obj, key: val })
React는 못 알아챔	React가 변경 감지함
렌더링 안 됨	렌더링 정상 작동

한줄정리

React는 "얕은 비교(shallow compare)"로 상태 변화 감지하기 때문에, 불변성(immutability) 을 유지하면서 새 객체/배열을 만들어줘야 한다.