2014년 세종도서 학술부문 기술과학분야 선정도서


차량용 소프트웨어를 개발할 때 알아야 할 주요한 소프트웨어 기술과 프로세스를 체계적으로 설명한 책이다. 이 책은 자동차 소프트웨어의 탄생 배경을 설명함으로써 시작한다. 일반적인 소프트웨어 개발자가 낯설어하는 자동차 개발 프로세스의 주요 특징과 자동차 개발 프로세스와 소프트웨어 개발 프로세스가 어떻게 연결되는지 알아봄으로써, 자동차 소프트웨어 개발의 특징을 이해할 수 있다. 아울러 첨단 자동차 소프트웨어 개발을 위해 사용되는 다양한 소프트웨어 기술, 표준, 네트워크를 살펴봄으로써, 자동차 소프트웨어 세계에 입문하는 개발자들에게 꼭 필요한 지식을 전달한다.


[ 소개 ]

자동차 소프트웨어 개발자가 알아야 할 소프트웨어 엔지니어링의 기초

소프트웨어를 개발한다는 측면에서 일반적인 소프트웨어나 차량용 소프트웨어는 별반 다르지 않다. 하지만 많은 인원이 참여하고 오랜 기간이 소요되는 개발 프로세스가 적용된다는 점, 사고 발생 시 인명 피해와 직결된다는 점, 다양한 공급자들이 제공하는 제어기들을 통합해서 개발한다는 측면에서 일반적인 소프트웨어와 차량용 소프트웨어의 차이는 명확해진다. 따라서 품질이 우수한 차량용 소프트웨어를 개발하기 위해서는 뛰어난 소프트웨어 개발 역량과 더불어 개발 프로세스, 소프트웨어의 안전을 확보하는 방법, 차량용 소프트웨어의 특징과 개발 방법, 차량용 네트워크에 대한 지식이 필요하다. 따라서 이 책은 차량용 소프트웨어 엔지니어링의 기초라고 할 수 있는 배경 지식을 전달하도록 구성됐다.


[ 이 책에서 다루는 내용 ]

■ 자동차 소프트웨어의 주요 특징
■ 자동차 소프트웨어 개발에 꼭 필요한 자동차 개발과 소프트웨어 개발 프로세스 특징
■ 안전한 자동차를 개발하기 위한 기능안전 기초 지식
■ 자동차 개발의 주요 표준인 AUTOSAR, OSEK-OS, EAST-ADL
■ CAN, LIN, FlexRay의 차량용 네트워크와 CCP, KWP2000의 주요 프로토콜


[ 이 책의 특징 ]

자동차 소프트웨어 개발에 꼭 필요한 지식과 최신 기술을 체계적으로 접근하고 다룬다.


[ 이 책의 대상 독자 ]

이 책은 차량용 소프트웨어 이외의 분야에서 소프트웨어 개발 경험이 있는 개발자를 위해 작성됐다. 따라서 이 책에서는 임베디드 소프트웨어 개발에 관한 일반적인 내용을 다루지 않는다. 만약 임베디드 소프트웨어 개발 경험이 없는 개발자라면 임베디드 소프트웨어 개발에 관한 기초 서적을 참고하길 바란다. 아울러 기계, 전기, 전자, 전산 분야를 전공한 학생들이 자동차 분야의 소프트웨어 개발을 시작한다면, 이 책에서 차량용 소프트웨어 개발에 대한 기초 지식을 얻을 수 있다. 앞서 설명했듯이 이 책에서는 임베디드 소프트웨어에 대한 일반적인 내용을 다루지 않기 때문에, 해당 분야의 지식이 없는 독자라면 관련 서적을 참고하길 바란다.


[ 이 책의 구성 ]

1장, 자동차와 임베디드 소프트웨어: 차량용 임베디드 소프트웨어가 등장한 배경을 중심으로 차량용 소프트웨어가 자동차에서 어떤 역할을 하는지 알아본다. 아울러 제어기 간의 통신이 필요한 이유를 살펴봄으로써 차량용 네트워크의 등장배경을 알아본다. 시스템 엔지니어링을 사용해 자동차 개발에서 발생하는 복잡성을 관리하는 것도 살펴본다.

2장, 자동차 개발 프로세스: 기획단계부터 양산단계까지의 일련의 프로세스를 살펴봄으로써 자동차 개발 프로세스에 대해 알아본다. 단계마다 개발되는 시험 자동차의 종류와 특징을 살펴보고, 각 시험 자동차에 어떤 종류의 소프트웨어 샘플이 탑재되는지도 살펴본다.

3장, 제어 개발 프로세스: 자동차 개발에 사용되는 시스템 엔지니어링의 특징을 알아본다. 시스템 엔지니어링 기법을 사용해 시스템 개발 프로세스와 소프트웨어 개발 프로세스가 어떻게 통합되는지도 살펴본다. 시스템 개발 프로세스와 소프트웨어 개발 프로세스의 단계마다 어떤 활동이 이뤄지고, 각 단계에서 사용하는 개발방법과 산출물도 알아본다.

4장, 기능안전: 자동차에 탑재하는 전자 부품이 늘어나면서 전자 부품에서 발생하는 안전문제가 매우 중요해졌다. 자동차 업계는 이런 문제를 해결하기 위해서 ISO26262라는 기능안전 표준을 제정해 사용하려고 한다. ISO26262는 광범위한 영역을 다루는 표준이기 때문에, ISO26262의 모든 것을 소개할 수 없다. 차량용 소프트웨어에서 기능안전의 개념을 어떻게 도입하는지를 파악하는 단서 확보 차원에서, ISO26262의 파트 6에 해당하는 소프트웨어의 표준을 살펴본다.

5장, EAST-ADL: 아키텍처 프레임워크의 개념에 대해 간략하게 살펴본다. 차량용 아키텍처 프레임워크의 하나인 EAST-ADL의 특징을 알아본다. EAST-ADL의 시스템 모델과 확장 모델의 세부 내용에 대해 살펴본다.

6장, AUTOSAR: 차량용 소프트웨어 표준인 AUTOSAR의 등장 배경을 알아본다. AUTOSAR의 아키텍처 구조인 ASW, RTE, 서비스 레이어 등에 대한 특징을 살펴본다. 마지막으로 AUTOSAR를 적용한다는 의미와 구현된 AUTOSAR를 사용해 차량용 소프트웨어를 개발하는 일련의 절차를 알아본다.

7장, OSEK-OS: OSEK 표준의 종류를 살펴본다. OIL 파일을 사용해 OSEK-OS를 설정하는 방법과 OSEK-OS의 구현 모드를 알아본다. 태스크의 기본 구조와 태스크 동작 방식을 살펴보고, ISR 설정 시 주의할 점도 알아본다. 또한 OSEK-OS에서 어떤 종류의 훅이 있는지 알아본다. 아울러 스케줄링, 알람, 이벤트, 자원, 메시지의 사용방법도 살펴본다.

8장, CAN: CAN은 차량용 네트워크로 가장 보편화된 프로토콜이다. CAN의 등장배경을 살펴보고 프로토콜 특징, 메시지 프레임 구조와 같은 CAN의 기초에 대해서 알아본다. 메시지를 어떻게 설계하는지를 통해 CAN을 사용한 통신 애플리케이션을 살펴본다. CAN 하드웨어의 간략한 내용과 CAN 구현을 위한 소프트웨어 구조, MCAL 개발 예제도 제시한다.

9장, LIN: LIN은 CAN보다 단순한 형태의 통신을 지원하기 위해 탄생한 프로토콜이다. LIN의 탄생 배경, 적용 분야, 통신 방식을 살펴본다. 아울러 메시지 구조를 알아보고, 간단한 예제를 사용해 LIN 메시지를 설계하는 방법을 제시한다. LIN의 하드웨어와 소프트웨어 구조를 살펴보고, LIN MCAL 설정 방법도 알아본다.

10장, FlexRay: FlexRay는 조향이나 제동과 같은 자동차의 안전과 직결되는 분야에서 사용하기 위해 탄생한 프로토콜이다. 이 장에서는 FlexRay가 안전을 보장하기 위해 어떻게 구현되고 있는지 살펴봄으로써 FlexRay 사용 시 필요한 기초 지식을 제공한다.

11장, CCP: 자동차 소프트웨어를 구현하는 것도 중요하지만, 구현한 소프트웨어를 차량에 탑재해 개발하는 과정에서 제어기의 성능을 알아봐야 한다. 이를 위해 제어 변수를 모니터링하고 측정해야 한다. 아울러 개발된 차량용 소프트웨어를 차량에 탑재해 목표한 성능을 끌어내기 위해, 성능 변수를 캘리브레이션해야 한다. 이때 대표적으로 사용되는 프로토콜이 CCP다. 이 장에서는 CCP의 특징과 통신방식, 구현방법에 대해 알아본다.

12장, KWP2000: 양산한 자동차는 폐기 처분할 때까지 짧게는 10년에서 20년이 넘는 기간이 걸린다. 따라서 여러 제조업체가 공급하는 차량에서 발생하는 고장을 정확하게 진단하기 위해서는 고장 진단 표준이 필요하다. 이런 요구를 수용해 고장진단 프로토콜인 KWP2000이 탄생했다. 이 장에서는 KWP2000의 특징과 통신 방식, 구현에 대해 살펴본다.

[ 저자 서문 ]

국제 가전 전시회(CES)는 얼마 전까지만 하더라도 가전제품 업체들의 각축장이었다. 하지만 2013년 미국 CES부터 전시회의 주인공이 바뀌었다. 바야흐로 스마트카가 새 주인공으로 떠올랐다. 영화 「백투더퓨처」의 주인공처럼 타임머신을 타고 과거에서 미래로 온 사람이 본다면 상당히 충격적인 이야기일 수 있다. 국제 가전 전시회의 주인공이 스마트카라니? 하지만 스마트폰을 필두로 한 IT 혁명을 경험한 우리에게 다음번 IT 혁명은 자동차에서 일어나리라는 예측이 억측만은 아니다.

스마트카 혁명을 이끌어 가는 원동력은 다양하지만, 그중에서 가장 핵심적인 것은 ‘소프트웨어’다. 확실히 스마트카 열풍이 불면서 과거보다 소프트웨어 관점에서 자동차에 접근하기가 쉬워졌다. 아울러 소프트웨어 개발자의 관점에서 본다면, 스마트카에 탑재되는 소프트웨어도 일반적인 소프트웨어와 그다지 차이가 없는 듯하다. 하지만 스마트카용 소프트웨어는 일반적인 가전제품과 달리 자동차에 탑재된다는 측면에서 진입 장벽이 높다.

자동차 사고가 발생하면 많은 인명 피해를 일으킬 수 있다. 따라서 안전에 매우 민감하다. 아울러 수만 개의 부품을 제어하기 위해 많은 제어기가 자동차에 탑재됨에 따라 부품과 제어기 간의 유기적인 결합이 매우 중요해졌다. 자동차는 가전제품과 달리 제품 개발 기간이 길 뿐만 아니라, 출고에서 폐차할 때까지 짧게는 10년에서 길게는 20년이 넘게 걸린다. 따라서 고장, 수리, 폐기 등의 문제도 여러 측면에서 고려해야 한다. 말하자면 스마트카의 등장으로 자동차 분야에서 소프트웨어의 중요성이 커졌지만, 소프트웨어가 자동차에 탑재돼 올바르게 작동하게 하기 위해서 자동차 분야의 특수성을 고려해야 한다는 사실은 변하지 않았다.

일반적으로 혁신은 아웃사이드-인(Outside-in) 방식이나 인사이드-아웃(Inside-out) 방식으로 일어난다. 아웃사이드-인은 다른 도메인이나 분야에서 사용하는 방법이나 적용되는 아이디어를 가져와 자신의 분야에 적용해 혁신하는 것이다. 이와 달리 인사이드-아웃은 내부 분야의 방법과 아이디어를 사용해 외부의 분야나 도메인으로 확산하는 것이다. 스마트카의 혁신에서, 일반 IT 기업이 IT를 자동차에 적용하려는 건 바로 아웃사이드-인 방식이고, 반대로 자동차 분야에서 자동차 기술을 IT와 접목해서 스마트카를 만들려는 건 인사이드-아웃 방식이다.

이 책의 저자들은 차량용 소프트웨어를 개발하기 전에, 이미 오랜 기간 다른 도메인의 소프트웨어를 개발했다. 소프트웨어 분야에서 오랫동안 경력을 쌓았음에도, 차량용 소프트웨어 분야에 적응하는 데 짧지 않은 시간이 필요했다. 이것은 앞서 설명한 차량용 소프트웨어의 특수성을 이해하는 시간이었다.

이 책의 목적은, 이런 저자들의 경험을 토대로 아웃사이드-인 방식으로 자신의 기술을 자동차 분야에 적용하려는 기업, 단체, 혹은 개인이 알아야 하는 차량용 소프트웨어 개발에 필요한 기초적인 엔지니어링 지식을 전달하기 위함이다. 이 목적을 달성하기 위해, 이 책은 개발 프로세스, 방법론, 차량용 소프트웨어에 특화한 소프트웨어 특징, 차량용 네트워크의 지식을 담고 있다.

이 책에서 차량용 소프트웨어에 대해 많은 것을 다루지만, 현업에서 소프트웨어를 개발하려면 다양한 경험과 지식이 필요하다. 이런 경험을 쌓고 지식을 습득하는 것은, 이 책의 내용을 바탕으로 독자 스스로 채워 나가는 몫으로 남겨 두겠다. 아무쪼록 이 책이 더 빠르고 더 편리하며 더 우수한 차량용 소프트웨어 개발에 이바지하길 바란다.

- 2013년 저자 일동


[ 저자 소개 ]

신승환
다양한 분야의 소프트웨어를 개발•관리•컨설팅했다. 현대오트론에서 책임 연구원으로 차량용 소프트웨어를 개발하고 있다. 관심 분야는 무인 자율 주행 시스템의 소프트웨어 개발이다. 『도와주세요! 팀장이 됐어요』를 포함한 다수의 IT 서적을 집필했다.

정민우
한양대학교 대학원에서 정보통신을 전공했으며, 현재 만도에서 선임 연구원으로 차량용 소프트웨어를 개발하고 있다. MCU, DSP, ARM 등 다양한 컨트롤러용 임베디드 소프트웨어 개발과 RTOS 이식 경험이 있다. 전력•전자 제어 및 소프트웨어 아키텍처 설계에 관심이 많으며, 차량용 임베디드 시스템 엔지니어가 되기 위해 노력하고 있다.

조선영
한양대학교 대학원에서 물리학을 전공했으며, 현재 현대오트론에서 책임 연구원으로 차량용 소프트웨어를 개발하고 있다. PC, 웹, 엔터프라이즈 애플리케이션 등 다양한 경험을 갖고 있으며, 차량 제어 분야의 요구공학 엔지니어와 소프트웨어 이키텍트로 활동하고 있다. 소프트웨어 아키텍처 설계와 개발 프로세스에 관심이 많으며, 자동차의 무인 자율 주행 시스템의 완성을 꿈꾸면서 차량용 소프트웨어를 개발하고 있다.

김연호
성균관대학교 대학원에서 제어 및 가상현실을 전공했으며, 현재 현대오트론에서 책임 연구원으로 차량 기능안전 대응 및 역량심사 업무를 하고 있다. 비주얼 컴퓨팅, 웹, B2B 솔루션, 국방 무기체계 등 다양한 SW 개발 경험을 갖고 있다. ISO 26262, 소프트웨어 아키텍처 및 모델 기반 시스템 엔지니어링 분야에 관심이 많으며, 설계•개발•프로세스가 잘 조화된 차량용 소프트웨어 엔지니어가 되기 위해 노력하고 있다.

목차

• 1장 자동차와 임베디드 소프트웨어
  • 1.1 자동차용 임베디드 시스템의 등장
  • 1.2 자동차용 네트워크의 등장
  • 1.3 자동차를 구성하는 서브시스템
    • 1.3.1 파워트레인
    • 1.3.2 섀시
    • 1.3.3 보디
    • 1.3.4 멀티미디어
  • 1.4 데이터 캘리브레이션
  • 1.5 자동차용 임베디드 소프트웨어 전망
    
• 2장 자동차 개발 프로세스
  • 2.1 자동차 개발 프로세스 개요
  • 2.2 기획 단계
  • 2.3 선행 개발 단계
  • 2.4 디자인 단계
  • 2.5 설계 단계
  • 2.6 시작 단계
  • 2.7 시험 단계
  • 2.8 생산 준비 단계
  • 2.9 양산 단계
  • 2.10 차량 개발 프로세스 모니터링과 통제
  • 2.11 전자 기술을 반영한 차량 개발 프로세스
    
• 3장 제어 개발 프로세스
  • 3.1 엔지니어링 프로세스
    • 3.1.1 차량 레벨상의 시스템 콘셉트
    • 3.1.2 시스템 요구사항 정의
    • 3.1.3 시스템 아키텍처 설계
    • 3.1.4 시스템 구현
    • 3.1.5 소프트웨어 요구사항 분석
    • 3.1.6 소프트웨어 아키텍처 설계
    • 3.1.7 소프트웨어 단위 설계와 구현
    • 3.1.8 소프트웨어 단위 검증
    • 3.1.9 소프트웨어 통합과 검증
    • 3.1.10 소프트웨어 확인과 배포
    • 3.1.11 시스템 통합과 검증
    • 3.1.12 차량 평가와 데이터 캘리브레이션
    • 3.1.13 시스템 배포
  • 3.2 지원 및 관리 프로세스
    • 3.2.1 프로젝트 관리 프로세스
    • 3.2.2 요구사항 관리 프로세스
    • 3.2.3 형상 관리 프로세스
    • 3.2.4 변경 관리 프로세스
    • 3.2.5 품질 관리 프로세스
      
• 4장 기능 안전
  • 4.1 기능안전 개요
  • 4.2 위험 관리 정의와 기능안전과 유사성
  • 4.3 HARA와 ASIL 설정
  • 4.4 안전요구사항 도출과 시스템 설계
  • 4.5 ASIL 분해
  • 4.6 소프트웨어 아키텍처 안전분석
  • 4.7 소프트웨어 개발과 검증
    
• 5장 EAST-ADL
  • 5.1 시스템 아키텍처의 정의와 역할
  • 5.2 아키텍처 프레임워크
    • 5.2.1 메타 모델링 아키텍처 프레임워크
    • 5.2.2 공통 아키텍처 프레임워크
    • 5.2.3 특정 도메인 아키텍처 프레임워크
  • 5.3 자동차 분야의 아키텍처 EAST-ADL
  • 5.4 EAST-ADL 시스템 모델
    • 5.4.1 EAST-ADL의 차량 레벨
    • 5.4.2 EAST-ADL의 분석 레벨
    • 5.4.3 EAST-ADL의 설계 레벨
    • 5.4.4 EAST-ADL의 구현 레벨
  • 5.5 EAST-ADL의 확장 모델
    • 5.5.1 EAST-ADL의 요구사항 모델링과 V&V
    • 5.5.2 EAST-ADL의 운영환경 모델링
    • 5.5.3 EAST-ADL의 신뢰성 모델링
    • 5.5.4 EAST-ADL의 가변성 모델링
    • 5.5.5 EAST-ADL의 거동 모델링
    • 5.5.6 EAST-ADL의 타이밍 모델링
      
• 6장 AUTOSAR
  • 6.1 AUTOSAR 등장 배경
  • 6.2 AUTOSAR 범위
  • 6.3 AUTOSAR 아키텍처 구조
    • 6.3.1 ASW
    • 6.3.2 RTE
    • 6.3.3 서비스 계층
    • 6.3.4 ECAL
    • 6.3.5 MCAL
    • 6.3.6 콤플렉스 드라이버
    • 6.3.7 인터페이스
  • 6.4 AUTOSAR 적용
    • 6.4.1 SW 컴포넌트 정의
    • 6.4.2 ECU 자원 정의
    • 6.4.3 시스템 정의
    • 6.4.4 시스템 설정 및 EUC 정의 추출
    • 6.4.5 ECU별 설정
    • 6.4.6 ECU별 SW 실행파일 생성
      
• 7장 OSEK-OS
  • 7.1 OSEK/VDX 개요
  • 7.2 OIL 설정
  • 7.3 응용프로그램 모드
  • 7.4 시작과 종료
  • 7.5 태스크
  • 7.6 ISR
  • 7.7 훅
  • 7.8 스케줄링
  • 7.9 알람
  • 7.10 이벤트
  • 7.11 자원
  • 7.12 메시지
    
• 8장 CAN
  • 8.1 초기 차량 네트워크
  • 8.2 CAN 탄생배경
  • 8.3 기본개념
  • 8.4 통신 방식
  • 8.5 메시지 구조
    • 8.5.1 메시지 프레임 구조
    • 8.5.2 데이터 프레임
    • 8.5.3 원격 프레임
    • 8.5.4 오류 프레임
    • 8.5.5 오버로드 프레임
  • 8.6 메시지 비트타임 세그먼트와 재동기화
  • 8.7 구현
    • 8.7.1 메시지 설계
    • 8.7.2 하드웨어
    • 8.7.3 소프트웨어
      
• 9장 LIN
  • 9.1 LIN 탄생 배경
  • 9.2 개요
    • 9.2.1 기본 개념
    • 9.2.2 적용 분야
  • 9.3 통신 방식
    • 9.3.1 에러 검출 및 제한
    • 9.3.2 슬립과 웨이크업
  • 9.4 메시지 구조
    • 9.4.1 프레임 종류
    • 9.4.2 메시지 프레임
    • 9.4.3 메시지 프레임 타입
  • 9.5 구현
    • 9.5.1 메시지 설계
    • 9.5.2 하드웨어
    • 9.5.3 소프트웨어
      
• 10장 FlexRay
  • 10.1 엑스바이와이어 기술
  • 10.2 FlexRay 탄생
  • 10.3 기본 사항
  • 10.4 프로토콜 아키텍처
  • 10.5 프레임 포맷
  • 10.6 통신 주기
    • 10.6.1 클록 동기화
    • 10.6.2 정적인 영역
    • 10.6.3 동적인 영역
  • 10.7 웨이크업과 스타트업 프로토콜
    • 10.7.1 웨이크업 단계
    • 10.7.2 스타트업 단계
  • 10.8 토폴러지
    • 10.8.1 수동형 버스 토폴러지
    • 10.8.2 듀얼 채널 싱글 스타
    • 10.8.3 싱글 채널 연속형 스타
    • 10.8.4 듀얼 채널 연속형 스타
  • 10.9 FlexRay 노드 아키텍처
    
• 11장 CCP
  • 11.1 탄생 배경
  • 11.2 특징과 응용분야
  • 11.3 인터페이스 표준과 구조
    • 11.3.1 인터페이스 메시지 구조
    • 11.3.2 CRO 메시지
    • 11.3.3 DTO 메시지
    • 11.3.4 CRM
    • 11.3.5 이벤트 메시지
    • 11.3.6 DAQ 메시지
  • 11.4 명령어와 인터페이스의 예
    • 11.4.1 명령어
    • 11.4.2 명령어 인터페이스의 예
  • 11.5 오류 처리
  • 11.6 드라이버 구현
    • 11.6.1 초기화
    • 11.6.2 DAQ 초기화 및 데이터 측정
    • 11.6.3 캘리브레이션 초기화
    • 11.6.4 드라이버 구현의 예
      
• 12장 KWP2000
  • 12.1 KWP 2000 등장 배경
  • 12.2 OBD의 통신 방법
    • 12.2.1 SAE-J1850
    • 12.2.2 ISO 15765
    • 12.2.3 ISO 14230
  • 12.3 KWP2000의 구조
    • 12.3.1 KWP 2000 - 파트 1
    • 12.3.2 KWP 2000 - 파트 2
    • 12.3.3 KWP 2000 - 파트 3
  • 12.4 KWP 2000 구현 방법
    • 12.4.1 소프트웨어 구조
    • 12.4.2 CAN 드라이버
    • 12.4.3 전송 계층