[자동차 소프트웨어 공학 다시 읽기] 2-1. 제어 시스템

 

이 글은 "자동차 소프트웨어 공학" 2장을 읽고 개인적으로 정리한 학습 노트 입니다.

책을 정리하다가 재밌게 읽었고, 지금 시점에서 다시 봐도 생각하기 좋은 부분들이 있기에 공유하고자 정리해봅니다.

책 정보: https://product.kyobobook.co.kr/detail/S000000855004

 

1장에서는 자동차를 더 이상 기계 장치만으로 설명할 수 없다고 보았습니다.

즉, 자동차는 센서, ECU, 액추에이터, 차량 네트워크, 소프트웨어가 결합된 전자 제어 시스템입니다.

엔진, 변속기, 브레이크, 조향, 차체 제어, 편의 기능, ADAS 기능은 모두 이런 전자 제어 시스템 위에서 동작하고 있습니다.

 

ECU 안의 소프트웨어는 차량을 어떻게 제어할까?

 

그 핵심에는 제어 시스템이라는 개념이 있습니다.

자동차 소프트웨어는 단순히 입력을 받아 출력을 내는 프로그램이 아닙니다. 차량이라는 물리 세계의 상태를 관찰하고, 목표 상태와 비교하고, 필요한 조치를 계산하고, 액추에이터를 통해 실제 차량의 움직임을 바꾸게 됩니다.

 

이 관점에서 자동차 소프트웨어는 본질적으로 제어 시스템의 일부라고 봐야 합니다.

 

자동차 소프트웨어는 현실 세계와 연결되어 있다

일반적인 많은 소프트웨어는 주로 디지털 세계 안에서 동작합니다. 웹 서비스는 사용자의 요청을 받고 데이터를 조회한 뒤 응답을 돌려주게끔 되어 있습니다. 모바일 앱은 화면을 그리고, 입력을 받고, 서버와 통신합니다. 물론 이런 소프트웨어도 복잡하고 중요하지만, 많은 경우 출력은 화면, 데이터, 메시지, 파일 같은 디지털 결과물이라고 할 수 있습니다.

 

그런데, 자동차 소프트웨어는 다릅니다. 자동차 소프트웨어의 출력은 차량의 물리 동작으로 이어질 수 있습니다. 엔진 토크가 바뀌고, 브레이크 압력이 조절되고, 조향 보조력이 달라지고, 서스펜션 감쇠력이 바뀌고, 에어백이 전개될 수도 있다는 말입니다. 소프트웨어의 판단이 실제 차량의 움직임과 탑승자의 안전에 직접 연결됩니다.

 

그래서 다음의 흐름을 함께 봐야 합니다.

현실 세계의 상태 → 센서 측정 → ECU의 소프트웨어 판단 → 액추에이터 제어 → 차량 동작 변화 → 다시 센서로 피드백

 

이 흐름이 바로 제어 시스템의 기본 구조라고 할 수 있습니다.

 

열린 루프 제어와 닫힌 루프 제어

제어 시스템을 이해할 때 가장 먼저 만나는 개념은 열린 루프 제어와 닫힌 루프 제어입니다. (국문으로 하면 이해가 잘 안될 수도 있습니다. 영어를 based 로 이해하면 빠르게 이해됩니다.)

 

열린 루프 제어는 출력 결과를 다시 확인하지 않고, 입력이나 명령에 따라 미리 정해진 동작을 수행하는 방식입니다. 예를 들어 특정 조건에서 워셔액을 일정 시간 분사하거나, 스위치 입력에 따라 모터를 일정 방향으로 구동하는 식의 단순 제어는 열린 루프에 가깝게 이해할 수 있습니다.

 

반면 닫힌 루프 제어는 실제 출력 결과를 센서로 다시 측정하고, 목표값과 비교하면서 제어를 조정하는 방식입니다. 흔히 말하는 피드백 제어의 경우입니다. 자동차에서는 닫힌 루프 제어가 매우 중요합니다.

예를 들어 크루즈 컨트롤을 생각해보면, 운전자가 목표 속도를 100km/h로 설정했다고 해서 ECU가 단순히 일정한 연료량이나 모터 출력을 계속 내보내면 안되는 경우가 많습니다. 도로 경사, 차량 하중, 바람, 노면 상태에 따라 실제 속도는 계속 달라지기 때문입니다. 따라서 시스템은 현재 속도를 계속 측정하고, 목표 속도와의 차이를 계산하고, 가속 또는 감속을 조정해야 합니다.

 

구분	열린 루프 제어	닫힌 루프 제어
핵심 특징	출력 결과를 다시 확인하지 않음	출력 결과를 측정해 다시 반영
센서 피드백	필수 아님	필수
장점	구조가 단순하고 빠름	외란과 오차에 대응 가능
한계	실제 결과가 목표와 달라질 수 있음	설계와 안정성 검토가 더 복잡함
자동차 예시	단순 스위치 기반 동작	속도 제어, 엔진 제어, 브레이크 제어, 차체 자세 제어

 

자동차 소프트웨어의 많은 핵심 기능은 닫힌 루프 제어에 가깝습니다. 왜냐하면 차량은 항상 외부 환경과 상호작용하기 때문이죠. 도로는 평탄하지 않고, 타이어 마찰은 변하며, 운전자의 입력도 계속 달라지게 됩니다. 차량의 무게, 속도, 경사, 주변 객체, 날씨 등 모두 영향을 주게 됩니다. 그래서 자동차 소프트웨어는 이 변화 속에서 차량 상태를 계속 관찰하고 조정해야 합니다.

 

피드백이 중요한 이유

피드백은 제어 시스템의 핵심입니다. 피드백이 없으면 시스템은 자신이 의도한 결과를 실제로 만들었는지 알 수 없기 때문입니다. 그렇다는 것은 피드백이 있으면 시스템은 목표와 실제 상태의 차이를 줄이는 방향으로 동작할 수 있습니다.

 

기능	피드백으로 사용할 수 있는 정보
엔진 제어	산소 센서, 회전수, 흡기량, 온도
브레이크 제어	휠 속도, 차량 속도, 제동 압력
조향 제어	조향각, 조향 토크, 차량 자세
차체 자세 제어	요레이트, 횡가속도, 휠 속도
ACC	전방 차량 거리, 상대 속도, 자차 속도
차선 유지 보조	차선 위치, 차량 횡방향 위치, 조향 상태

 

이러한 피드백 구조 때문에 자동차 소프트웨어는 현실 세계와 끊임없이 연결될 수 있다고 생각합니다.

 

센서가 틀리면 제어도 흔들리고, 센서가 늦으면 판단도 늦어지게 됩니다.

또한 액추에이터 반응이 예상과 다르면 제어 결과도 달라지게 됩니다. 따라서 자동차 소프트웨어에서는 센서, 제어 알고리즘, 액추에이터, 차량 동역학을 분리해서 생각하기 어렵다는 점. 이러한 부분이 일반적인 애플리케이션 소프트웨어와 자동차 소프트웨어의 큰 차이라고 할 수 있습니다. 

 

소프트웨어는 연속적인 부분을 끊어서 본다

우리 환경도 차량도 물리적으로 연속적이라고 할 수 있습니다. 속도는 계속 변하고, 조향각도 연속적으로 변하며, 가속도와 제동력도 시간에 따라 변합니다. 하지만 ECU 안의 소프트웨어는 이 연속적인 부분들을 그대로 다룰 수가 없습니다. 

소프트웨어는 센서 값을 일정 주기로 읽고, 계산하고, 출력한하는데 있어서 이러한 부분들을 샘플링된 값으로 다룹니다. 

 

여기서 중요한 문제가 생기게 됩니다. 현실 세계는 계속 연속적으로 변하고 있는데, 소프트웨어는 특정 시점의 값을 바탕으로 판단하는 점이 문제를 만들 수 있게 됩니다. 샘플링 주기가 너무 느리면 중요한 변화를 놓칠 수 있습니다. 또한 계산이 늦어지면 이미 상황이 바뀐 뒤에 제어 명령이 나갈 수 있습니다.

 

예를 들어 AEB, 자동 긴급 제동 기능을 생각해보면 전방 객체와의 거리를 카메라나 레이더 데이터를 일정 주기로 받아 객체를 인식하고, 충돌 위험을 계산하고, 제동 여부를 판단합니다. 여기서 센서 주기, 인식 지연, 판단 주기, 제동 액추에이터 반응 시간 등이 모든 면에서 영향을 주게 됩니다. 따라서 자동차 소프트웨어에서는 “계산이 맞는가”뿐 아니라 “충분히 빠른 시점에 계산되었는가”도 중요하게 됩니다. 

이러한 시스템을 실시간 시스템이라고 부릅니다. (이 부분은 다음에 별도로 다뤄보겠습니다)

 

자동차 기능은 상태를 가진다

자동차의 기능은 단순히 켜짐과 꺼짐만으로는 설명되자가 않습니다. 기능은 여러 상태를 가지고, 어떤 조건에 따라 상태가 전이/천이 되게 됩니다. 예를 들어 ACC 기능을 단순화하면 다음과 같은 상태를 생각할 수 있습니다. 

Unavailable → Standby → Active → Degraded → Fault

 

상태	의미
Unavailable	기능을 사용할 수 없는 상태
Standby	기능은 준비되었지만 아직 제어하지 않는 상태
Active	기능이 실제로 차량 속도나 거리를 제어하는 상태
Degraded	일부 조건이 나빠져 제한적으로 동작하는 상태
Fault	고장이나 이상으로 기능을 중단해야 하는 상태

 

상태 머신이 중요한 이유는 기능의 책임과 경계를 명확하게 만들기 때문입니다.

기능이 언제 활성화될 수 있는지, 언제 비활성화되어야 하는지, 고장이 발생하면 어떤 상태로 가야 하는지, 운전자에게 무엇을 알려야 하는지, 다른 시스템에는 어떤 정보를 보내야 하는지를 상태 기반으로 정의할 수 있습니다.

 

자율주행과 ADAS 기능에서는 상태 정의가 특히 중요합니다.

단순히 “차선을 유지한다”, “앞차와 거리를 유지한다”는 기능 설명만으로는 부족합니다. 어떤 조건에서 기능이 시작되고, 어떤 조건에서 제한되며, 어떤 상황에서 운전자에게 제어권을 넘기고, 어떤 상태를 안전한 상태로 볼 것인지 정의해야 합니다.

 

즉 상태 머신은 오래된 소프트웨어 설계 기법처럼 보이지만, 지금의 자율주행 및 기능 안전에서도 여전히 중요한 도구라고 할 수 있습니다.

 

전통적인 제어 시스템과 지금의 자율주행

15년 전 자동차 소프트웨어 공학에서 제어 시스템은 주로 ECU 기반의 차량 기능을 설명하기 위한 기초 개념이었습니다. 엔진 제어, 변속기 제어, 브레이크 제어, 차체 자세 제어처럼 센서 입력을 받아 제어 알고리즘을 실행하고 액추에이터를 움직이는 구조가 중심이었습니다.

 

15년 후 지금도 이 구조는 그대로 남아 있습니다. 하지만 자율주행과 ADAS에서는 제어 루프가 더 길고 복잡해졌습니다. 전통적인 제어 기능은 비교적 명확한 물리량을 다루는 경우가 많았습니다. 속도, 회전수, 온도, 압력, 조향각, 휠 속도 같은 값들 말이죠.

반면에 자율주행 기능은 추가로 주변 환경을 해석해야 합니다. 차선은 어디에 있는지, 앞차는 어떤 객체인지, 보행자는 움직일 가능성이 있는지, 옆 차량이 끼어들 것인지, 현재 차로에서 주행을 계속해도 되는지 판단해야 한다는 말입니다.

Sense → Perceive → Predict → Plan → Control → Act

 

센서가 데이터를 수집하고, 인지 시스템이 객체와 차선을 해석하고, 예측 시스템이 주변 객체의 움직임을 예상하고, 계획 시스템이 주행 경로와 행동을 정하고, 제어 시스템이 차량을 움직이게 합니다. 

지금의 자율주행도 큰 관점에서는 제어 루프라고 할 수 있습니다. 다만 그 루프 안에 AI 기반 인식, 예측, 판단, 경로 계획이 들어오면서 설명과 검증이 훨씬 어려워졌다는 점에서 차이가 있습니다. 

 

SDV 에도 제어 루프는 사라지지 않는다

SDV를 이야기할 때 우리는 소프트웨어 플랫폼, OTA, 클라우드, 서비스 지향 아키텍처, 데이터 기반 개발과 같은 주제로 이야기를 많이 합니다. 하지만 SDV가 된다고 해서 자동차가 물리 시스템이라는 사실이 사라지는 것은 아니라는 점을 명심해야 합니다. 아무리 차량 기능이 소프트웨어로 정의되고 업데이트된다고 해도, 마지막에는 차량이 실제 도로 위에서 움직인다는 것이죠.

즉, 조향, 제동, 가속은 여전히 시간과 물리 법칙의 제약을 받는 것은 똑같고, 이러한 제어루프는 SDV 에도 동일하게 적용됩니다. 

어쩌면 더 중요해진다고도 할 수 있습니다. 왜냐하면 기능이 계속 업데이트될수록, 제어 루프 안의 어떤 부분이 바뀌었는지 명확히 알아야 하기 때문이죠. 센서 처리 로직이 바뀐 것인지, 판단 로직이 바뀐 것인지, 제어 파라미터가 바뀐 것인지, 상태 전이 조건이 바뀐 것인지 구분할 수 있어야 합니다.

 

OTA 이후에는,

• 업데이트된 소프트웨어가 기존 제어 안정성을 깨뜨리지 않는가?
• 상태 전이 조건이 바뀌면서 예상하지 못한 모드 전환이 생기지 않는가?
• 센서 처리 지연이 늘어나 제어 성능에 영향을 주지 않는가?
• 특정 조건에서 fallback 상태로 제대로 전이되는가?
• 기존 테스트 케이스로 충분히 검증할 수 있는가?

저는 SDV의 핵심은 소프트웨어를 빨리 바꾸는 데만 있어서는 안된다고 생각합니다. 소프트웨어를 바꿔도 차량이 안전하게 동작한다는 것을 반복적으로 설명할 수 있어야 SDV를 제대로 보고 있다고 생각합니다.

 

기능안전과 SOTIF 관점에서 다시 보기

제어 시스템을 안전 관점에서 보도록 하겠습니다. 

 

첫 번째는 고장에서 센서가 고장 나면 어떻게 할 것인가? ECU 내부 계산이 잘못되면 어떻게 감지할 것인가? 액추에이터가 명령대로 움직이지 않으면 어떻게 대응할 것인가? 이 질문은 기능안전, 즉 ISO 26262의 관점과 연결됩니다.

 

두 번째는 고장이 없어도 위험할 수 있는 상황으로 센서는 정상 동작했지만 인식 성능의 한계로 객체를 놓쳤다면 어떻게 볼 것인가? 제어기는 고장 나지 않았지만 설계된 기능 범위 밖의 상황을 만났다면 어떻게 할 것인가? 운전자는 시스템이 할 수 있는 것보다 더 많은 것을 기대하고 있다면 어떻게 할 것인가? 이 질문은 SOTIF 관점과 연결된다.

 

센서 단선이나 ECU 고장은 기능안전의 전형적인 관심사다. 반면 강한 비, 눈, 역광, 특이한 도로 구조, 예측하기 어려운 끼어들기 상황은 SOTIF의 관심사에 더 가깝다고 할 수 있습니다. 따라서 제어 시스템을 공부할 때 단순히 “목표값과 실제값의 차이를 줄인다”는 수준에서 멈추면 부족할 수 있습니다. 다음 질문까지 이어져야 할 것입니다.

• 무엇을 측정하고 있는가?
• 그 측정값은 믿을 수 있는가?
• 측정하지 못하는 상황은 무엇인가?
• 제어 목표는 언제 유효한가?
• 기능이 동작하면 안 되는 조건은 무엇인가?
• 기능 한계에 도달했을 때 어떤 상태로 전이해야 하는가?
• 운전자나 다른 시스템에는 무엇을 알려야 하는가?

이러한 질문들이 자동차 소프트웨어 공학을 단순한 제어 알고리즘 설계에서 시스템 안전 설계로 확장시킬 수 있다고 생각합니다.

 

15년 전 개념을 현재 관점으로 다시 정리하면

주제	15년 전에는	지금의 해석은
제어 시스템	센서, ECU, 액추에이터의 기본 구조	차량 기능 전체를 구성하는 피드백 루프
열린 루프 제어	단순 명령 기반 제어	제한된 조건에서만 유효한 비피드백 제어
닫힌 루프 제어	센서 피드백 기반 제어	ADAS/자율주행의 기본 구조
이산계	연속 신호를 디지털 시스템에서 처리	샘플링, 지연, 데이터 주기가 안전성과 연결
상태	시스템 동작 모드	ADAS 상태, fallback, degraded mode, ODD 관리
제어 로직	ECU 내부 알고리즘	AI 인식, 판단, 계획, 제어가 결합된 시스템 루프
검증	제어 기능이 목표대로 동작하는지 확인	기능 한계, 시나리오, OTA 이후 회귀 검증까지 포함

 

제어 시스템의 기초 개념은 지금도 유효합니다. 아니 이러한 개념이 적용되는 시스템의 범위가 훨씬 넓어졌다고 생각하는것이 바람직할 것입니다.

 

마무리

이번 글에서 제가 설명하는 포인트를 요약하면, 자동차 소프트웨어는 현실 세계와 분리된 코드가 아니라는 것입니다. 센서가 현실을 측정하고, 소프트웨어가 그 값을 해석하고, 액추에이터가 차량의 물리 동작을 바꿉니다. 그리고 그 결과는 다시 센서를 통해 시스템에 돌아오는 피드백 구조가 자동차 소프트웨어에서 중요하다는 점입니다. 

 

전통적으로 이 구조를 ECU 기반 제어 시스템으로 설명했지만, 지금은 같은 구조를 ADAS, 자율주행, SDV, OTA, SOTIF까지 확장해서 봐야 합니다. 즉, 자율주행도 결국은 같은 제어 루프이고 고려해야 할 부분들이 더 크다는 점만 차이가 있을 뿐입니다. AI 인식, 상황 예측, 행동 계획, 운전자 상호작용, 기능 한계 관리, 안전 상태 전이가 들어오면서 훨씬 복잡해졌기 때문입니다. 그래서 자동차 소프트웨어를 공부할 때 제어 시스템을 먼저 이해하는 것은 여전히 중요합니다.

 

코드를 보기 전에 루프를 먼저 생각해야 하고, 알고리즘을 보기 전에 상태를 봐야 합니다. 그리고 기능을 보기 전에 그 기능이 어떤 조건에서 안전하게 동작할 수 있는지 봐야 한다고 말씀 드립니다. 

 

이상 읽어 주셔서 감사합니다.