[웨비나 다시보기] Tier 실무자를 위한 오토사(AUTOSAR) 활용 전략 - 웨비나 - RESOURCES - 페스카로(FESCARO)

6월 19일(수) 개최된 페스카로의 <Tier 실무자를 위한 오토사 활용 전략> 웨비나가 성황리에 마무리되었습니다.

오토사는 소프트웨어 구조를 표준화하여 개발 편의성 · 범용성 · 확장성을 향상함으로써, 소프트웨어에 대한 다양한 요구와 변화에 유연하게 대응할 수 있습니다. SDV(소프트웨어 중심 자동차)시대에서 생존하기 위한 #오토사, 그 실무 노하우가 궁금하신가요? 지금 웨비나를 확인해 주세요.

■ 전문가 패널 소개

• 자동차 소프트웨어 개발 전문가 구성서 상무 & 최희선 팀장 : 자동차 제어기 및 보안솔루션 포함한 임베디드 시스템 SW 개발 경력 20년+

• 자동차 미들웨어 전문가 이순철 부사장 : 애플리케이션 엔지니어, 프로젝트 매니저, 한국지사 대표이사직까지 경력 30년+

■ 질문 LIST

1. SDV 시대, 제어기 개발사의 당면 과제는 무엇인가요?

2. 오토사가 무엇인가요?

3. 오토사는 하나만 적용하면 되는 것 아닌가요?

4. 오토사를 어떻게 적용하나요? 실제 사례가 궁금해요.

5. ASW 및 BSW 개발 시 고려해야 할 부분은 무엇인가요?

6. 사이버보안을 만족시키려면 오토사를 꼭 써야하나요?

7. 오토사 Authoring 툴을 효과적으로 사용하는 방법이 있나요?

8. 자동화했을 때 코드 변경으로 인한 영향이 없나요?

9. 검증은 어떻게 하나요?

■ 영상 Ver.

■ 텍스트 Ver.

1. SDV 시대, 제어기 개발사의 당면 과제는 무엇인가요?

Tier의 당면과제

SDV(소프트웨어 중심 자동차) 시대의 혁신적인 변화 속에서, 제어기 개발자 여러분이 겪는 어려움을 잘 알고 있습니다. 특히 SDV의 전환에는 몇 가지 중요한 과제에 직면해 있습니다. 주요 장애물은 다음과 같습니다.

• 소프트웨어 복잡성 : 증가하는 소프트웨어 복잡성을 관리하는 동시에 신뢰성과 안전성 보장이 필요합니다.

• 사이버보안 : 방대한 양의 데이터를 사이버공격 및 개인 정보 침해로부터 보호하려면 강력한 암호화와 안전한 데이터 저장이 필요합니다.

• 규제/법적 체계 : ADAS(첨단 운전자 지원 시스템) 관련 포괄적인 규정 개발 및 책임 문제 해결을 위해, 정부와 업계 이해관계자 간 협력이 필요합니다.

• 상호 운용성 및 통합 : 다양한 공급업체의 소프트웨어 구성 요소를 응집력 있는 시스템으로 통합하려면, 표준화 및 산업 간 협업이 필요합니다.

• 기술 발전 및 비용 관리 : 급속한 기술 발전과 지속적인 업데이트 시 비용 증가 및 개발 복잡성이 증가합니다.

이러한 소프트웨어 표준화 노력·안전·성능·사용자 경험 향상을 위해 탄생한 것이 ‘오토사(AUTOSAR)’입니다.

2. 오토사가 무엇인가요?

오토사는 AUTomotive Open System Architecture의 약자로 , 자동차 산업을 위한 개방형 시스템 아키텍처입니다. 이 아키텍처를 통해 공급업체별 다양한 소프트웨어 및 하드웨어 구성 요소가 원활하게 작동할 수 있습니다.

오토사 컨소시엄의 슬로건은 "표준에서는 협력하고, 개발로 경쟁하자"입니다. 따로 고민하지 말고 협력해서 좋은 아키텍처와 표준화된 규격을 만들어 준수하면 완성차 제작사(OEM), 제어기 개발사(Tier) 모두에게 이득이 된다는 접근입니다. 그럼 오토사가 앞서 설명드린 당면과제를 어떻게 해결할 수 있는지 보겠습니다.

오토사(AUTOSAR) 이점

• 표준화된 모듈식 프레임워크 : 모듈성은 전체 시스템에 영향을 주지 않고, 구성 요소의 독립적인 개발 · 업그레이드 · 교체가 가능합니다.

• 보안 지침 정의 및 자동화된 보안테스트 도구 : 자동화 도구는 취약점을 탐지하며 제어기 간 상호 작용을 보장하고, 개발 및 테스트를 간소화합니다. 또한 검증을 통해 제어기 신뢰성 · 성능 · 보안을 보장합니다.

• 소프트웨어 업데이트 규제(UN R156) 관련 OTA 업데이트 표준 제공 : 자동화된 시스템으로 업데이트 배포를 처리하며, 검증 프로세스로 업데이트 안정성을 확인합니다.

• 표준화된 아키텍처 제공 : 다양한 공급업체의 제어기가 원활히 작동하도록 보장합니다. 또한 소프트웨어 컴포넌트를 여러 프로젝트나 차량 모델에서 재사용할 수 있습니다.

• 유연성과 확장성 개선 : 새로운 기능과 업데이트를 쉽게 통합할 수 있습니다. 차량의 복잡성과 데이터 요구 사항을 지원하여 개발 비용 절감 · 혁신 가속화 · 유지 관리 및 업데이트 개선 · 이해관계자 간 협업 강화를 이룰 수 있습니다.

오토사는 이미 많은 완성차 제작사와 제어기 개발사에서 채택하여 사용하고 있습니다. 오토사 파트너사인 BMW, 포드(Ford), GM, 토요타(Toyota), 폭스바겐(Volkswagen), 현대차그룹 등이 있습니다. 이러한 사용 사례들은 오토사 필요성과 효과를 명확히 입증합니다.

오토사 계층화구조

이제 오토사 계층화 구조에 대해 설명드리겠습니다. 오토사에는 #ASW, #BSW, #RTE가 포함됩니다. ASW는 Application SW 모듈로 엔진 제어, 브레이크 시스템 등의 특정 기능을 구현합니다. BSW는 Basic SW 모듈로 하드웨어 추상화와 메모리 관리 등의 기능을 포함합니다. RTE는 Run-time Environment를 말하며, ASW와 BSW 간의 데이터 흐름을 관리합니다. 이 구조는 모듈화된 소프트웨어 개발과 상호 운용성을 촉진합니다.

ASW는 하드웨어와는 별개로 독립적으로 재활용되기 위해 VFB(Virtual Functional Bus) 상에서 설계됩니다. 물론 ASW는 오토사라는 새로운 플랫폼에 맞추어야 합니다. 이 VFB를 실제 구현하기 위해 BSW에서는 상당히 많은 작업을 필요로 합니다. 키보드로 핸드 코딩을 하던 것에서 마우스로 Configuration하는 것으로 개발 방식이 바뀌었습니다. 오토사 구현에는 최소 100~200KB의 플래시 메모리가 필요합니다. 고도로 통합된 고급 제어기에서는 일반적으로 1~4MB 플래시 메모리가 필요합니다.

3. 오토사는 하나만 적용하면 되는 것 아닌가요?

Classic오토사와 Adaptive오토사

요즘 SDV(소프트웨어 중심 자동차) 차량은 Classic 그리고 Adaptive 오토사(AUTOSAR)가 함께 적용되고 있습니다. Classic 오토사 플랫폼은 엔진 제어 및 제동 시스템과 같이 실시간 기능이 필요한 기존 기능에 이상적입니다. 반면 Adaptive 오토사 플랫폼은 ADAS 및 인포테인먼트와 같은 고성능 애플리케이션에 적합합니다. 두 플랫폼을 결합하면 확장성, 유연성 및 미래 보장성을 제공하여 차량에 새로운 기술을 적용할 수 있습니다. 두 개의 오토사를 적용하는 제조사는 BMW, 폭스바겐(Volkswagen), 현대자동차 등이 있습니다.

오토사 솔루션 선택 시 고려사항

그럼 오토사 솔루션 선택 시 고려해야 할 부분에 대해 알아보겠습니다. 우선 MCU의 가용성과 호환성이 핵심 요소입니다. 오토사 솔루션은 각종 유틸리티 및 라이브러리를 포함한 툴체인, Authoring 툴의 사용자 경험(UX) 편리성, 규정 준수 및 지원 측면에서 대상 칩셋과 잘 맞아야 합니다. 이를 통해 원활한 개발 프로세스와 안정적·효율적인 자동차 소프트웨어 시스템이 보장됩니다.

또 한 가지 고려할 사항은 다양한 완성차 제작사의 요구 사항과 표준을 충족하기 위해 표준 아키텍처를 조정해야 합니다. 이는 사용자 지정 확장, 안전, 보안 및 성능 향상을 포함합니다. 이러한 요구 사항을 충족하면 제조사는 업계 표준을 준수하면서도 유일한 기능으로 시장에서 두각을 나타낼 수 있습니다.

시장에는 수많은 오토사 공급업체가 존재합니다. 각 오토사 공급업체마다 라이선스 및 유지보수 조건, 가격이 다르니 비교해 보시기 바랍니다. 또한 구매 후 발생하는 교육 및 엔지니어링 지원에 대한 부분도 점검하시길 추천드립니다.

4. 오토사를 어떻게 적용하나요? 실제 사례가 궁금해요.

페스카로 오토사 플랫폼 적용 사례

우선 국내 최대 완성차 제작사(OEM)인 H사에 공급되는 제어기의 대부분은 모빌진 오토사(AUTOSAR)가 적용되고 있습니다. 하지만 해외 OEM이나, H사를 제외한 국내 OEM을 대상으로 하는 제어기는 모빌진이 아닌 ETAS나 Vector, EB사의 오토사 플랫폼을 적용해야 합니다.

페스카로도 KG 모빌리티를 대상으로 한 게이트웨이 개발 시 오토사 플랫폼을 적용한 사례가 있습니다. 초기 주어진 개발 기간이 너무 짧아 자체 플랫폼을 개발할까도 생각했지만, 동작상의 안정성 및 시장에서의 신뢰성 등을 고려하여 검증된 플랫폼인 오토사를 적용하게 되었습니다. 플랫폼을 비교할 때는 개발에 걸리는 기간, 가격, 지원이 얼마나 잘 되는지, 그리고 게이트웨이 기능이 포함되어 있는지 등을 고려하여 업체를 선정했습니다.

결과적으로 페스카로는 2개월만에 오토사를 적용했습니다. 게이트웨이 기본 기능인 메시지 라우팅과 시그널 라우팅, 그리고 진단 일부 기능들까지 동작하는 게이트웨이 소프트웨어를 개발했습니다.

오토사 개발 프로세스

그럼 일반적인 오토사 개발 프로세스를 설명드리겠습니다.

1. 제어기 요구사항과 함께 고객사로부터 CAN DBC 및 진단 CDD, 구현되어야 할 DTC, 네트워크에 관한 정보 등을 전달받습니다.

2. 전달 받은 CAN DBC 및 진단 CDD를 오토사 툴에서 Import하고, 나머지 정보들은 툴에서 configuration 작업을 완료합니다.

3. 저장을 하면 arxml 파일이 생성됩니다. 이 arxml에는 BSW에서 설정한 configuration 정보를 포함하여, ASW의 SW-C에 대한 입출력 및 Runnable의 호출 주기도 포함되어 있습니다.

4. 다음으로 BSW code generation 과정을 통해 BSW의 설정값들이 포함된 arxml을 기반으로 BSW의 코드가 생성됩니다. RTE code generation을 통해 Runnable의 호출 및 ASW의 소프트웨어 컴포넌트 입출력 인터페이스와 관련된 코드가 생성됩니다.

5. ASW 정보가 포함된 arxml을 이용해서 Matlab과 같은 모델링 툴로 로직을 구성하여 어플레이케이션 소스코드를 생성할 수도 있습니다.

6. 마지막으로 Generation된 소스코드를 컴파일러툴로 빌드하면 제어기에 올라가는 펌웨어 이미지가 생성됩니다. 이 이미지를 타겟 즉, 제어기 MCU에 다운로드 하여 동작을 확인할 수 있습니다.

오토사는 제어기 개발사(Tier)에게 좋은 부분이 많지만 충분한 고민도 필요합니다. 오토사 적용 이점은 대부분 다 아실텐데요. 개발자 입장에서 봤을 때 MCAL, BSW, RTE and OS Configuration 등 대부분 Configuration에 의해 코드가 Generation되기 때문에, 사람에 의한 코딩 실수를 현저히 줄일 수 있다는 것입니다. 대신 많은 설정이 필요합니다. CAN 메시지와 시그널, 필요한 진단 기능 등은 CAN DBC와 진단 CDD 등의 파일들을 이용해 오토사 툴에 Import시 CAN과 관련된 설정은 어느 정도 자동으로 되지만, 이외에도 많은 Configuration을 필요로 합니다.

그래서 오토사를 처음 접하는 개발자들에게는 오토사 플랫폼을 도입하는 것이 다소 생소하고, 진입 장벽이 높아 쉽지 않은 작업입니다. 사전에 충분한 교육과 경험을 쌓은 후 도입하시길 추천드립니다.

5. ASW 및 BSW 개발 시 고려해야 할 부분은 무엇인가요?

제어기 개발 시 고려사항

오토사(AUTOSAR) 플랫폼을 이용해 제어기를 개발할 경우, 가장 필요한 점은 제어기 시스템의 사양, MCU를 포함한 HW에 대한 이해, 시스템의 기능에 대한 정확한 분석과 입출력에 대한 정의 및 설계라고 할 수 있습니다. 이 부분은 사실 오토사 플랫폼을 이용하지 않더라도 제어기 개발에 있어 가장 기본적이며 중요한 부분입니다.

앞서 설명 드렸듯 오토사를 사용하는 목적 중 하나로 재사용성을 말씀드렸는데요. 제어기 하드웨어가 변경되더라도 제어기 기능이 변경되지 않고 입출력이 변경되지 않았다면, ASW(Application SW) 영역은 수정 없이 새로운 하드웨어에서 재사용할 수 있습니다.

ASW 개발 시 고려사항

다음으로 ASW 개발을 위해 고려해야 할 사항은 제어기의 기능별 정의, 기능별 필요한 입출력에 대한 정리가 되어야 하며, 이 기능들이 어떤 시간 주기로 실행되는지 확인해야 합니다. 이 부분이 정리된다면 Matlab과 같은 모델 베이스로 개발하던, 수동으로 코딩을 하던 BSW와는 독립적으로 가상의 RTE 환경을 이용하여 ASW 개발이 가능하게 됩니다. 나중에 BSW(Basic SW) 개발이 완료되었을 때 Integration 과정을 통해 시스템이 완성됩니다.

RTE는 앞서 설명드린 것과 같이 Run-Time Environment입니다. RTE는 ASW에서 기능별로 구현된 Software Component들 간에 주고 받는 데이터, 소프트웨어 Component와 BSW 간에 주고받는 시그널 또는 데이터를 전달하는 Virtual Function Bus 역할을 한다고 보시면 됩니다. RTE는 ASW와 BSW 사이에 위치하여 서로 주고 받는 데이터들을 정의함으로써 RTE 가상화가 가능하게 되고, ASW와 BSW를 분리하여 독립적인 개발이 가능하도록 합니다.

BSW 개발 시 고려사항

대부분 BSW 개발 시 설정하는 내용들을 가장 어려워하여 관련 고민이 많으실 것 같습니다. 오토사의 핵심이라고 할 수 있는 BSW를 보면 System, Memory, Communication Service, HW Abstraction과 CDD라고 불리는 Complex Driver 영역이 있습니다. 하나씩 설명 드리겠습니다.

• System Service : Os, Mcu, BswM, WdgM, Dem, Gpt 모듈 등으로 구성되어 있습니다. 시스템 전반적으로 사용되는 서비스를 애플리케이션과 BSW 모듈에 제공하는 역할을 하며, 아래와 같은 것들을 고려해야 합니다.

- Os 모듈 : 실행 주기와 우선순위를 가지는 각종 Task들, 인터럽트 사용 유무 및 실행될 ISR 연결, Mutual Exclusive를 위한 리소스들을 설정해야 합니다.

- Mcu 모듈 : 시스템 운영에 필요한 기본적인 Clock들을 설정해야 합니다. 제어기 동작 모드 즉 Normal, Sleep, Standby 모드 등을 설정합니다.

- BswM 모듈 : 시스템 운영을 포함하는 모드들과 해당 모드에서 실행되어야 할 Action List들을 설정합니다.

- Gpt(General Purpose Timer) 모듈 : 시스템에서 사용되는 Timer들에 대한 설정을 합니다.

- Watchdog 모듈 : 소프트웨어가 멈추거나 정의해 놓은 시간 주기를 초과하는 경우, 실행 순서를 어기는 경우 등을 설정하여 시스템이 오작동 시 재시작할 수 있도록 합니다.

- Dem 모듈 : 보통 알고 있는 DTC로 제어기 동작 중 오작동을 발견할 경우 NVRAM에 기록해놓고, 클러스터 등에 이 동작 상태를 보고하여 사용자가 인식할 수 있도록 합니다.

• Memory Services : 시스템이 꺼졌다 켜져도 남아 있는 데이터를 저장할 수 있는 Nvram 모듈이 대표적입니다. 주로 DTC 와 관련된 정보나 진단을 통해서 읽고 쓰는 데이터들이 저장됩니다. 사용되는 Flash의 Configuration 설정이 Main Chipset이나 Flash 스펙에 맞게 제대로 설정이 되어야 하며, 저장될 항목에 대한 설정이 필요합니다.

• Communication Service : CAN과 관련된 통신 모듈에 대한 설정이 필요합니다. CAN DBC 및 진단 CDD를 오토사 툴에서 Import시 기본적인 메시지 또는 시그널에 대한 configuration이 어느 정도 자동으로 진행된다고 말씀드렸는데요. 이외 게이트웨이의 경우 라우팅이 필요한데, 이때는 PDU-R 모듈에서 개별적으로 Tx와 Rx 메시지에 대한 매핑이 필요할 수 있습니다.

• I/O Hardware Abstraction : Adc, Dio, Port, Spi, Uart 등과 같은 MCU의 Input, output port들을 사용하기 위한 BSW 영역입니다. 실제 하드웨어 핀들에 대한 설정과 해당 핀들의 사용 용도에 맞게 설정이 필요합니다.

• CDD : 오토사 BSW/MCAL에서 제공되지 않는 서비스를 구현해야 할 때, 개발자에 의해 직접 인터페이스 정의 및 구현되어야 하는 영역입니다. 오토사에서 따로 인터페이스가 제공되지 않으므로, 자유롭게 인터페이스를 정의하고 구현하면 되므로 어렵게 생각할 필요는 없습니다.

그렇다면 ASW와 BSW를 효율적으로 개발하는 방법도 궁금하실텐데요. 제품에 대해서는 제어기 개발사(Tier)가 가장 잘 알고 있기 때문에 ASW는 직접 개발하여 내재화 하는 것이 옳은 방법입니다. 하지만 제어기 및 하드웨어에 대해 잘 알고 있다 하더라도, BSW 개발은 Configuration 해야 할 항목들이 워낙 많아서 쉽게 접근하기 힘들 수 있습니다. 그래서 오토사를 이용하여 직접 제품을 개발하여 납품한 경험도 있고, 여러 오토사 툴을 많이 접해 본 페스카로 같은 전문 업체와 협업하면 효율적이고 빠르게 제품을 개발할 수 있지 않을까 생각됩니다.

6. 사이버보안을 만족시키려면 오토사를 꼭 써야하나요?

페스카로 사례

정확하게 말씀 드리면 필수는 아닙니다. 오토사(AUTOSAR)가 나오기 전에도 이미 CAN 동작이 그러하였듯 사이버보안도 구현되어 동작하고 있었습니다. 오토사가 소프트웨어 모듈의 재사용, 품질과 신뢰성을 높일 수 있기 때문에 개발되었듯 사이버보안 관련 내용도 이와 마찬가지라고 할 수 있습니다.

ASW(Application SW)에서 사이버보안을 위한 기능들이 실행될 때, 오토사 BSW의 Crypto Service Layer에서 CSM이란 모듈을 제공하고 있습니다. 이 CSM 모듈은 전자서명 검증, MAC 생성, 암복호화, Random Seed 생성 등 대부분 사이버보안을 위한 인터페이스를 제공하고 있습니다.

하지만, 당사 보안 게이트웨이는 인증서별로 다르게 부여된 진단 기능을 허용하고, 인증된 인증서를 가진 장비만 진단 포트 접근이 가능하도록 사이버보안 기능을 강화했습니다. 그래서 BSW(Basic SW)에서 기본으로 제공되는 CSM 모듈을 사용해서는 강화된 게이트웨이의 사이버보안 기능을 모두 사용할 수가 없어 Crypto MCAL위에 CDD_Crypto를 직접 구현하여 이러한 기능들을 적용했습니다.

이렇게 함으로써 MCU가 변경되더라도 MCAL Layer에서 Crypto 모듈을 설정한다면 사이버보안 모듈을 재사용할 수 있습니다. 또한 이미 수차례 검증된 소프트웨어이므로 구현 및 검증에 걸리는 시간을 줄일 수 있다는 장점이 있습니다.

오토사 플랫폼 및 사이버보안 모듈 적용은 페스카로와 같은 전문 업체에 맡겨 개발하는 것도 하나의 방법이 될 수 있을 것 같습니다. 페스카로는 이러한 소프트웨어 구조를 잘 설계하고, 이미 적용하여 양산한 경험이 있기 때문에 관련하여 궁금하신 부분이 있다면 연락 부탁드립니다.

7. 오토사 Authoring 툴을 효과적으로 사용하는 방법이 있나요?

오토사(AUTOSAR) 플랫폼 종류

자동화를 하나의 방법으로 말씀드리고 싶습니다. 지난 자관법 웨비나와 위의 답변에서 언급한 것과 같이, 오토사(AUTOSAR)는 보통 오토사 솔루션 공급사가 만들어 판매합니다. 이것을 오토사 패키지라고 표현하는데요. 오토사 페키지에는 Configuration Tool, 다른 말로 Authoring Tool과 BSW 그리고 RTE(Run-time Environment)가 포함되어 있습니다.

오토사 취지 중 하나가 휴먼 에러, 결국 사람이 하는 실수를 최소화하는 것이고 이를 충족 시키기 위해 Configuration Tool/Authoring Tool을 통한 코드 생성 방법을 사용합니다. 그래서 Vector의 Microsar는 다빈치, ETAS 오토사의 경우 ISOLAR, Elektrobit의 EB Tresos의 경우 EB Tresos studio, Mobilegene의 경우 Mobilegene C studio와 같은 툴이 사용됩니다.

이렇듯 오토사를 사용하면 configuration만으로 검증된 코드를 생성하여 사용 할 수 있다는 장점이 있습니다. 그러나 Configuration Tool의 사용이 그렇게 간단하지 않고 세세한 설정이 필요합니다. 세세한 설정 항목들이 많아지면 configuration 과정 중 휴먼 에러가 발생할 소지가 있습니다. 그리고 configuration 과정 중 유사한 configuratio을 여러번 반복해야 하는 경우가 빈번히 발생합니다. 결국 tool에 대한 사용 숙련도에 따라 상당히 많은 시간과 노력이 많이 드는 작업이라고 볼 수 있습니다.

Configuration을 자동화한다면 사용성 개선을 통해 진입장벽도 낮출 수 있고, 휴먼 에러도 줄일 수 있으며, 반복적인 configuration 작업을 최소화 할 수 있습니다. 결과적으로 개발 생산성을 극대화할 수 있고 결과물에 대한 일관성과 신뢰도도 높일 수 있습니다.

현재 대부분의 Authoring 툴에서 일부 configuration은 자동화해주지만, 전체 project 단위의 configuration 하기에는 부족합니다. 특히 HW와 SW를 재활용하여 제어기를 차량 단위로 파생하거나 타완성차 제작사(OEM)에 대응할 때, 대부분은 재활용하고 일부분만 변경해야 하는 경우에 자동화를 해준다면 그 효과는 매우 큽니다.

configuration 자동화

일례로 진단 DTC 관련 전체 configuration을 하기 위해서는 DEM service에 DTC 항목을 추가해야 하지만 이외 각 DTC code에 필요한 NVRAM 및 FEE configuration, 그리고 ASW에서 DTC 상태 파악 및 Event 설정을 위한 Port configuration 또한 해야 합니다. Authoring 툴에서 DEXT 파일을 import 하여 DEM service에 DTC 항목을 설정하지만, 나머지 NVRAM/FEE 및 ASW Port 설정은 따로 해야 하고 DTC 항목이 많을 경우 각 항목을 반복적으로 진행해야 합니다. 이 과정에서 일부 항목을 누락하거나 잘못된 정보로 연결될 경우 정상적인 DTC 동작이 이루어 지지 않습니다. 이러한 부분 configuration을 자동화 한다면 앞에서 이야기 했듯이 시간적 효율화 및 결과물의 신뢰도를 극대화 할 수 있습니다.

8. 자동화했을 때 코드 변경으로 인한 영향이 없나요?

당연히 있습니다. 다만 자동화할 경우에는 그로 인한 변경 사항이 예측 가능합니다. 왜냐하면 configuration을 자동화할 때 보통 그 결과를 이미 검증했기 때문입니다.

하지만 configuration 자동화에 따른 변경 사항도 일반 수정사항과 마찬가지로 우리가 예측한 것과 다른 영향을 줄 수 있습니다. 때문에 자동화든 아니든 사소한 configuration을 변경한 경우에도 반드시 제어기 전체 기능 검증이 필요합니다. 보통 우리는 이런 것을 Regression Test, 회귀 테스트라고 합니다. 변경 전에는 문제 없이 정상 동작하던 것이 변경 후 비정상적으로 동작하는지 확인하는 테스트입니다. SW 개발 과정에는 반복적으로 회귀 테스트가 진행됩니다. 매번 SW 업데이트마다 manual로 전체 기능 검증을 수행하기란 쉽지가 않고 리소스, 시간이 또한 많이 소요됩니다. 이를 해결 하기 위해 검증 과정 또한 자동화가 필요합니다.

반복적인 테스트를 효과적으로 수행하기 위해 보통은 HIL(Hardware In The Loop), SIL(Software In The Loop)등을 구성하여 testing을 자동으로 수행합니다. 말 그대로 제어기를 실차와 비슷한 가상화 환경 구성하는 것인데, HIL은 Hardware를 기반으로 한 각종 장비를 이용하여 테스트 환경을 구성하고 실제 제어기를 연결하여 테스팅을 수행합니다. SIL은 SW를 통해 가상환경을 구성하여 이 가상화 환경에서 SW를 동작하게 하여 테스팅을 수행합니다. 아직까지는 HIL을 통해 테스팅 자동화를 많이 구성합니다. 다만 SW의 기술과 복잡도 등이 많이 발전하고 있는 상황이어서 SIL의 사용 빈도도 증가하고 있는 추세입니다.

페스카로 사례

페스카로도 제어기를 개발 시 전문업체와 HIL을 함께 제작하거나 HIL을 직접 만들어 사용하기도 합니다. HIL을 사용하면 Test Case별 필요한 입력 및 요구되는 결과를 설정하여 자동으로 전체 Test Case의 수행 및 수행 결과를 reporting 할 수 있습니다.

9. 검증은 어떻게 하나요?

자동화가 핵심입니다. 검증 활동은 특정 단계에서 특정한 환경을 구성하여 진행하는 것이 아니라 초기 설계 단계부터 개발이 한창 진행 중인 단계, 개발이 완료된 단계 등에서도 전개되어야 합니다. 단계별로 검증 목적과 기대되는 결과 그리고 사용하는 도구들이 모두 다릅니다.

설계 단계에서는 보통 설계 결과의 적정성이나 합리성, 일관성, 완성도 등을 리뷰하는 활동을 통해 전개합니다. 사이버보안 관점에서 예시를 말씀드리면 사이버보안 컨셉을 만드는 과정, 사이버보안 목표를 수립하고 요구사항을 만드는 과정이라고 보시면 됩니다. 이 과정에서도 도출된 결과들이 정확한지, 완결되었는지, 일관성이 있는지 등을 검토하여 결과물의 품질을 확보하기 위한 검증 활동이 일어납니다. 모델기반으로 설계를 하는 경우에는 MIL(Model In The Loop)를 구성하여 검증하는 경우도 있습니다.

실제 SW를 구현하는 단계에서는 Code Review, 정적 검증, 동적 검증, 단위시험 등의 활동을 많이 하게 됩니다. 각 검증을 하나씩 설명드리겠습니다.

검증 종류

• Code Review : 팀 혹은 담당자 단위로 정기/비정기적으로 수행합니다. 툴(예 : Gerrit)을 도입해 코드 리뷰 활동을 강제화할 수 있습니다.

• 정적 검증 : 상용툴(예 : Coverity)을 사용하며 MISRA나 CERT-C와 같은 기준을 적용합니다. 개발이 거의 마무리되는 단계에서 정적 검증 활동을 한 번에 수행할 경우 Defect 대응을 위한 코드 수정이 개발 마무리 단계에서 발생하여 구현 동작에 영향을 줄 수 있습니다. 정적 검증은 개발 진행 중 주기적으로 수행하는 것이 효율적입니다.

• 동적 검증 : 일반적으로 ISO 26262에서 정의하는 검증 방법을 따라 진행합니다. 다양한 Tool이 있지만 페스카로는 주로 Vector CAST를 사용합니다. 페스카로는 동적 검증 단위를 화이트박스 테스트로 단위 테스트(Unit Testing)를 진행하고, 구문 커버리지(Statement Coverage)와 분기 커버리지(Branch Coverage)등의 실행 목표를 100%로 진행하고 있습니다.

• 단위 시험 : 보통 기능이나 모듈 단위로 많이 진행하며, 해당 단위에서 목표한 기능이 정상적으로 잘 동작하는지를 검증합니다.

• 통합 검증 : 개발이 마무리되는 단계에서는 통합 검증을 수행합니다. 통합 검증은 앞에서도 이야기 했듯이 HIL 환경을 구성하여 실차에서 검증하기 전에, 제어기 단위로 충분한 검증을 수행해야 실차 검증 단계에서의 효율을 극대화할 수 있습니다.

페스카로 기능검증

조금 더 이해를 돕기 위해 페스카로가 개발했던 사례를 들어 설명 드리겠습니다. 저희는 CGW(Central Gateway)를 개발했고 이를 위한 기능 검증은 크게 1)기본 동작 검증과 2)사이버보안 동작 검증으로 구분하여 진행했습니다.

1. 기본 동작 검증 : CGW가 가져야 하는 기능이 차량이나 완성차 제작사(OEM)에 따라 크게 다르지 않기 때문에 HIL(Hardware In The Loop)장비 전문업체와 함께 제작하여 사용하고 있습니다. 저희가 특히 신경 썼던 것은 차량 모델의 변경에 따라 달라지는 CAN 정보를 기반으로 Test Case를 자동으로 생성하는 것, 이 결과에 따라 testing이 자동으로 수행되며 결과 리포트까지 자동으로 만들어지도록 하는 것이었습니다.

2. 사이버보안 동작 검증 : 사이버보안 기능과 관련해서 OEM에 따라 그 요구사항이 굉장히 specific하여 별도의 HIL장비를 만들어 사용했으며, 이것 또한 test case 생성부터 수행, 결과 리포트 작성까지 자동화될 수 있도록 했습니다.

자동차 그리고 제어기에 있어서 SW의 비중이 점점 증가하고 있어 누가 더 효율적이면서도 안정적으로 SW 개발을 하느냐가 생존에 직접적인 영향을 주게 됩니다. 오토사(AUTOSAR)처럼 표준화되거나 재활용성이 높은 Platform SW를 선택하는 것도 그 이유입니다. 개발도 개발이지만 특히 검증 활동은 시간과 비용이 많이 들고 반복적으로 수행되어야 하기 때문에 자동화를 어떻게 할 것이냐가 매우 중요합니다.

페스카로는 사이버보안 전문기업으로 시작해서 현재는 제어기를 만들기도 하고 제어기 SW 개발과 관련된 협업도 많이 추진하고 있습니다. SW개발이나 검증과 관련하여 다양한 의견을 나누고 고민 해결까지 해드릴 준비가 되어 있으니, 언제든 연락 부탁드립니다.

■ 보너스 질문

이렇게 끝내기 아쉬운 분들을 위하여 웨비나 사전 등록 시 문의주신 내용을 추가로 다뤘습니다. 위에서 다룬 내용들 외에 가장 궁금해하시는 질문 5개를 선정했습니다. 전문가 패널의 답변이 궁금하신 분들은 영상을 통해 확인해주세요. (32:00부터~)

1. 현재 국내 oem이 제공하는 오토사 솔루션을 사용하고 있는데 해외 OEM은 어떻게 준비해야 하나요?

2. 오토사 첫 도입 시 사전에 준비할 사항은 무엇이고 진행 시 유념해야 할 사항이 궁금합니다.

3. 공급 업체들이 오토사 적용 확대 관련 어떤 고민과 애로사항이 있는지 궁금합니다.

4. Classic 오토사가 Adaptive 오토사로 완전히 대체될 수 있을까요?

5. 오토사 재활용에 대한 방법론이 알고 싶습니다. ASW 변경에 따른 BSW 재활용에 대한 설계 방법이 있나요?

■ 웨비나 소감 이벤트 당첨자

오토사 활용 전략에 대한 페스카로의 실무 노하우, 어떠셨나요? 웨비나를 통해 오토사에 대한 궁금증이 많이 해소되셨기를 바랍니다. 웨비나에 대해 솔직한 소감을 보내주시면 저희에게 많은 도움이 됩니다. '여기'에서 어느 부분이 도움이 되었고 어느 부분이 아쉬웠는지 솔직한 소감을 작성해주시면, 여러분의 의견을 수렴해 더 좋은 웨비나로 돌아오겠습니다.

ㆍ염* "오토사 플랫폼을 도입했는데 어떤 방향으로 공부할 지 도움이 되었습니다. 오토사를 미리 준비할 수 있는 좋은 기회입니다."

ㆍ홍*문 "웨비나는 더 현장감있게 진행해도 좋을 것 같습니다. 실시간으로 질의응답 시간을 늘리면 좋겠습니다."

ㆍ정*문 "오토사 솔루션 도입 시 도움이 중요 체크포인트들을 잘 요약 설명해 주셔서 매우 유익한 시간이었습니다."

■ AID 2024에서 만나요!

페스카로가 7월 4일(목) 'AID(Automotive Innovation Day) 2024'에 참가합니다. AID는 AEM(오토모티브 일렉트로닉스 매거진, Automotive Electronics Magazines)이 개최하는 미래 모빌리티 기술 전략 컨퍼런스입니다. 업계 전문가 수십 명이 1천여 명의 참관객을 대상으로 자율주행 · SDV · e모빌리티 등 3개 세션에서 인사이트를 전합니다. 페스카로가 참가하는 세션은 다음과 같습니다.

시간	장소	발표자	구분	주제
09:55 ~ 10:25	가야금 홀 (2F)	홍석민 대표	기조 연설	SDV 시대, 경쟁의 본질이 달라진다
10:50 ~ 11:20	거문고 A홀(3F)	이현정 상무	Connected&SDV	SDV 핵심 경쟁력, SW 중심 운영관리
16:25 ~ 17:25	가야금 홀 (2F)	홍석민 대표	패널 토론	Creating Synergy : How Players Share the Autonomous Mobility Ecosystem

특히, 미래 모빌리티를 이끌 신진 기업 CEO 4인과 함께하는 <패널 토론>이 이목을 끌고 있습니다. '자율주행 모빌리티 생태계에서의 시너지 창출'을 주제로 KATECH(한국자동차연구원)의 유시복 박사님(의장), 페스카로 홍석민 대표님, 오토노머스에이투지(AUTONOMOUS a2z) 한지형 대표님, 소네트(SONNET) 차두원 대표님, 스트라드비젼(STRADVISION) 김준환 대표님으로 구성된 매력적인 라인업에 업계의 기대를 모으고 있습니다. 많은 관심과 참석 부탁드립니다.

PREV	[무료 웨비나] Tier 실무자를 위한 오토사 활용 전략

RESOURCES

SITEMAP