AUTOSAR의 최근 개발 동향

AUTOSAR

소프트웨어의 인프라 구축을 명문화하기 위해 AUTOSAR의 개발 협력사는 보다 저렴한 시스템으로 활용할 수 있도록 추가적인 새로운 방법을 개발하고 있다. 이를 위해 표준으로 개발한 내용을 효과적으로 지원하고자 초기에 정리 조정과 적합성을 시험하는 과정을 설정하고, 보유한 해법부터 AUTOSAR 표준까지 유연하게 통합하는 방법을 강구하고 있다. 이에 따라 상용 목적으로 개발한 최초의 완전한 규격서가 발행될 예정이다. 또한 AUTOSAR 개발 협력사는 자동차 산업에 유용한 표준화 작업을 통해 얻은 결과를 제 2단계로 진행시키기 위해 준비하고 있다.AUTOSAR 개발 위원회자동차의 전자 기술과 함께 관련 소프트웨어의 기능상 활용 범위를 확장하기 위해서는 먼저 복잡한 구조를 획기적으로 감축하여 산업용으로 폭넓게 표준화된 소프트웨어의 인프라를 구축하는 방법이 필요하다. 이러한 목적에서 AUTOSAR 개발 위원회가 공식적으로 설립되어 현재 주된 업무를 맡고 있다. 이 위원회는 10개의 주요 파트너 사와 함께 부품 제조업체부터 툴과 소프트웨어 벤더, 반도체 제조업체 그리고 자동차 제조업체 자체에 이르는, 전반적인 자동차 전기 전자 제조업체의 여러 활동적인 공헌자로 이루어진 48개의 프리미엄 멤버사가 지원하고 있다. 이들 회원사의 기본적인 목적은 소프트웨어 인프라 구축이다. 낮은 인터페이스에 있는 하드웨어부터 높은 인터페이스인 애플리케이션 층의 소프트웨어까지 소프트웨어 아키텍처 층 범위에서 기술적인 방법을 제공하는 것이 그러한 예이다. 그러나 위원회의 노력이 소프트웨어 인프라 구축에 국한된 것은 아니다. 표준화된 템플릿과 데이터 교환 포맷을 기본으로 한 일관성 있는 방법론의 설계와, 호환성이 있는 인터페이스의 규격을 확장하는 데에 위원회는 초점을 맞추고 있다. 또한 기술적이고 절차적인 가이드라인은 자유 경쟁 아래의 표준 개발을 지원하기 위해 규격이 설정돼 있다.AUTOSAR 주된 업무 현황최근 AUTOSAR 개발 위원회는 상용 개발을 목적으로 전체 규격을 완성하는 단계에 있다. 또한 기본 개념을 입증·증명하는 부분의 일환으로, 기술적인 표준의 보완을 통해 규격의 실용화 시험을 실시하고 있다.표준화 방법AUTOSAR 개발 위원회는 엄격한 일정에 따른 요구를 관리하기 위한 단계적인 전략을 선택했다. 그림 1은 이런 방법을 실현하는 단계를 제시하고 있다.첫 번째 단계의 주 대상은 인프라스트럭처 수준에서 핵심 기능을 확립하는 데 있다. 2005년 중반, 위원회는 규격 집단을 이끌었으며 AUTOSAR 1.0을 발표했다. 그림 2는 인프라스트럭처 수준에서 첫 번째 발표의 두 가지 내용이다.일정을 유지하고자 이런 추가적인 방법으로 전체적인 개념과 개별적인 모듈 규격을 입증하기 위해 초기부터 점검 포인트를 만들었다. 그림 3에 개념 연구법을 논증하기 위한 2가지 단계를 나타낸다.기본적으로 유효성 검사 1과 2는 원형을 실현하기 위하여 집약한 것이며, 이들 유효성 검사 단계는 개별적으로 AUTOSAR 회원사에서 수행하는 기본 개념의 입증과 증명 활동으로 보완된다.결론적으로 AUTOSAR 위원회의 초기 단계의 기본 방침은 규격의 제공(즉, 기본적으로 서류 상의 작업), 입증된 품질 보증 방법을 선택했다. 이런 방법은 최종 규격을 발행하기 전에, 연속적으로 실현하고 완성시키기 위해 발생하는 오류를 검출하고 해결하여, 각각 2가지 프로토타입의 실현과 종합하는 단계를 원칙으로 한다.유효성 검사 1 실행2005년 가을, 유효성 검사 1에 대한 실현을 위해 그림 2의 RTE 이하에서 기본적인 소프트웨어를 집중적으로 동작시켰다. 이들 동작은 14개 참여 업체(AUTOSAR 파트너와 회원사)와 통합사가 업체와의 협동으로 준비했고, AUTOSAR 팀이 동의를 얻어 조정했다.총 31개 다른 종류의 소프트웨어 모듈(56개를 개별적으로 실현)을 실현하여, 결과적으로(각각 16비트와 32비트 마이크로컨트롤러를 기본으로 하는 평가 보드) 2개의 플랫폼으로 통합했다. 이 과정에서 종속적인 하드웨어와 독립적인 하드웨어로 검증하는 방법을 선택했으며, 가능성 있는 개념으로 입증하기 위해 적용 후 여러 가지 모듈에 대한 실현을 교대로 확인했다.그 결과, 변경해야할 규격이 260가지 이상 발생했다. 이에 대해, 첫 규격을 정리한 후에 종합적인 단계에서 기본적으로 그 개념을 변경했으며 이를 통해 초기 단계에서 구성상의 방법을 크게 수정하여 주요 문제점을 효과적으로 해결했다. 유효성 검사 1의 기본 목적과 얻은 결과로 AUTOSAR 규격을 확실하게 확인했다. 이는 프로토타입 실현을 성공적으로 시험한 것을 입증한다. 그러므로 조정 과정에서 모든 규격이 높은 수준으로 완성되었음을 알 수 있다. 유효성 검사 1에 의해 실현된 모듈은 AUTOSAR 역할에 기반하여, AUTOSAR 회원사에 엄격하게 공급되어 유효함이 실증됐다.AUTOSAR 2.0의 발표그림 2와 같이 AUTOSAR 2.0에는 소프트웨어 인프라 구축을 보완하여 더 많은 모듈에 규격이 추가됐다. 기존의 모듈 규격을 업데이트 하고 누락된 특성을 개선해, 이전에 검출할 수 없었던 항목을 제시하여 모듈 환경을 향상시켰다. 또한 조정 가능한 변경 절차를 도입해 유효한 활동에서 얻어진 변경 결과를 적용했다. 주요 개선 사항은 모든 규격의 타당성과 관련된다. 경험과 1.0에서 얻은 교훈 및 유효성 검사 1은, 2006년 초에 완성됐으며 개정 발표된 2.0에 획기적인 영향을 미쳤다. 발표된 2.0 규격의 주요 부분은 AUTOSAR 웹사이트에서 자유롭게 다운로드할 수 있다. 이들 규격은 단지 정보 제공만을 목적으로 하는데, 개발 단계를 위한 초기 준비에 효과적이다. 이 규격은 AUTOSAR 회원사만이 상용으로 개발할 수 있다.유효성 검사 2 실행발표된 2.0 규격은 현재 유효한 방법으로 실행되고 있으며, 12개 실행사와 1개 종합사에 배부되어 있다. 2.1로 발표될 결과는 상용화 할 목적으로 계속 개발 중이다.새로운 기술적인 개념발표된 규격 2.0은 다른 기술적인 영역과 마찬가지로 기본적인 소프트웨어 영역을 규정한 규격이다(그림 4). AUTOSAR 기본 소프트웨어(BSW)는 잘 알려진 기반 요소를 바탕으로 하여 구성, 오류 수정 등과 같은 여러 가지 새로운 BSW-확장 개념을 도입했다. 무엇보다 중요한 것은 포괄적이거나 제한적인 인프라스트럭처 구축이 자동차 제조 회사와 부품 공급 업체의 기술과 경험을 강화하거나 보완하는 데 유용하다는 것이다.동작 시간과 환경(RTE)추상적인 관점에서(즉 시스템 설계 시에) RTE는 지정된 ECU에서 가상적으로 기능하는 버스(VFB)의 동작 시간 실현이다. VFB의 개념은 응용 계층의 소프트웨어와 관련된 모든 통신 기구에 전달된다. 결론적으로 RTE는 하드웨어 관점과 기본 소프트웨어의 상세한 실현으로 응용 계층을 추출한다. 이런 측면에서 RTE는 네트워크를 통하여 응용 계층의 소프트웨어 부분을 전달할 수 있는 새로운 미들웨어 계층 기술이다.그림 5에 응용 계층 기능에 대해 통신할 수 있는 기구(여기서는 고객의 서버를 기본으로)의 예를 표시한다. 이런 통신은 RTE를 통해 전달된다. 기본 소프트웨어의 통신 계층은 캡슐화 되어 응용 계층을 볼 수 없다. AUTOSAR는 명료한 프로그래밍 언어 매핑과 부분적인 요구 사항 및 능력 기술을 위한 파일 포맷의 표준 구성 모델을 정의한다. 통신 기구 및 개념과 관련된 스케줄링으로 구성된 구성 모델로서, RTE는 잘 구성하여 결합된 부분에 응용 소프트웨어 계층을 구성한다.이 부분은 프로젝트에 대한 개념 단계나 이론 상에서 ECU로 이전하여 실현되므로 품질 보증과 함께 획기적인 노력으로 기술력과 시험을 줄일 수 있다.확장된 구성 개념여러 가지 다중 구성의 지원은 프리 컴파일, 링크 타임과 포스트-빌드 파라미터 구성 등급 또는 결합된 것을 활용한다.AUTOSAR는 XML 구성의 정의를 포함한 기본 소프트웨어 모듈의 능력과 파라미터를 기술하여 포맷을 정한다. 이런 설명을 통하여 원천적인 에디터(그림 6)는 하나의 ECU에 모든 소프트웨어 모듈을 편집하여 사용할 수 있다. 이것은 에디터 공급자가 실행하는 것으로 오늘날에는 불가능한 제품과 기술력의 속도와 제품의 품질을 제고하여 편리한 기능과 구성을 점검하는 것을 포함한다. 기본 소프트웨어 모듈용 AUTOSAR 규격은 모듈 제공자가 모듈 수정의 다중 모드를 제공할 수 있도록 허용하고 있다. BSW 모듈은 다음 항목을 활용하여 설계할 수 있다.- 최적의 동작 시간에 동작하는 편집 시간의 구성- 최상의 유연성을 위한 동작 시간의 구성- 2가지 경계 간을 교환하기 위한 연결 시간의 구성편집 시간과 연결 시간의 구성은 앞에서 기술한 바와 같이 원천적인 에디터로 발생하는 모듈 구성 설명 파일을 기본으로 하여 코드를 구성하여 활용한다. 결과적으로 AUTOSAR는 자동차 소프트웨어의 집중적인 개발을 위해 엄격하게 결합된 툴 체인을 지원하는 방향으로 나가고 있다.인프라스트럭처에서 추출구조의 첫 번째 세부 관점으로서 CAN 통신의 스택을 그림 7(그림 2와 비교)에 나타낸다.CAN 통신 서비스는 CAN을 이용한 자동차 네트워크 통신용 모듈의 집단이다. 이것들을 응용해서 프로토콜과 메시지 기능이 숨어 있는 CAN 네트워크에 균등한 인터페이스를 제공한다. AUTOSAR COM과 진단 통신 관리자는 버스 기술과 관계없는 응용으로 균등한 통신 기구를 제공한다. PDU 라우터는 한 버스에서 다른 버스로 공정 데이터 유닛의 직접 라우팅을 할 수 있다. 추가로 AUTOSAR COM 내에서 신호를 기본으로 하는 게이트웨이는 하나의 통신 시스템에서 다른 시스템으로 단일 신호 노선을 보내기 위해 개설되어 있다. 네트워크 관리는 독립된 버스와 종속된 버스로 분할된다.만일 CAN이 FlexRay로 교체되면 원천적인 NM은 동일하게 남는다. CAN 인터페이스를 도입한 PDU 라우터는 CAN 컨트롤러가 임베디드 컨트롤러든 외부 장치의 부분이든 상관없다. CAN에 종속된 모듈 대신 LIN이나 FlexRay 모듈로 교체하면 CAN 통신 스택은 LIN이나 FlexRay 통신 스택으로 전환할 수 있다.그림 8은 두 번째 예로써, AUTOSAR 아키텍처의 메모리 스택을 표시한다. NVRAM 관리자로서 주어지는 메모리 서비스는 불휘발성 데이터에 애플리케이션의 균등한 액세스를 제공하며 데이터의 위치와 성질에서 메모리를 추출한다. 더불어, 데이터의 저장, 로딩, 체크섬(checksum)의 보호와 입증과 같은 데이터 관리나 신뢰성 있는 저장과 같은, 불휘발성 데이터를 위한 메커니즘을 제공한다. 메모리 하드웨어 추출은 주변 메모리 디바이스(온칩이나 온보드)와 ECU 하드웨어의 위치에서 추출한다. 예를 들면 EEPROM 인터페이스와 플래시 하드웨어는 동등한 기구를 통하여 쉽게 접근할 수 있다.메모리 드라이버는 지정된 추출/에뮬레이션 모듈(EEPROM 추출 등)의 메모리를 통하여 접근한다. EEPROM 인터페이스와 플래시 하드웨어 유닛을 에뮬레이팅 함으로써 메모리 하드웨어의 두 타입에 메모리 하드웨어 추상화를 통해 일반적인 접근이 가능해진다. CAN 통신 스택과 메모리 스택의 두 가지 예는 모듈화의 최적을 달성하기 위한 수준 높은 모듈화와 전혀 다르게 사용하는 경우의 기반 소프트웨어 재사용을 보여준다.오류의 처리확실하고 일관성 있는 오류 처리는 응용 프로그램 계층 기능에 대한 효율적 통신을 지원하며, 모드 관리와 진단 목적으로 사용된다. 사용 예에는 센서의 고장, 통신의 오류와 메모리 불량이 포함된다.오류 처리에는 기본 소프트웨어 모듈과 RTE 양측에 대한 시스템을 통해 오류 정보 전파를 규정하는 기구가 있다. 그러므로 모든 API 기능은 애플리케이션 소프트웨어 구성의 계층에서 각각 기본 소프트웨어 모듈 규격을 잘 정리한 오류 코드를 돌려 보낸다. 확인된 진단 사항은 클라이언트 모듈에서 직접 해결되거나 상위 소프트웨어 계층으로 확대될 수 있다. 또한 어떤 진단 사항의 발생은 그림 9에 표시한 바와 같이 AUTOSAR 기본 소프트웨어로 제공되는 2개의 오류 처리 기능 중 하나에 보고된다.첫 번째 설정인 개발 오류 추적자(DET)는 통합이나 실행 단계에서 관심이 있는 진단 사항을 보고하기 위하여 활용된다. DET는 요구되는 방법으로 진단 사항을 보고하기 위하여 시스템 통합을 구성할 수 있으며 정상적으로 동작하는 동안에는 활용할 수 없다.정상적으로 동작하는 동안 감시되는 진단 사항은 진단 사항 매니저(DEM)에 보고된다. DEM을 진단 사항 메모리에 발생된 상황을 이해하는 기능을 구성하거나 동작 모드나 또는 응용 소프트웨어의 임의 기능을 저지하는 기능을 형성할 수 있다.기능의 인터페이스시스템에서 응용 소프트웨어 부분을 쉽게 통합하기 위해 인터페이스의 확실한 의미를 기능상으로 분류하여 정한다. 표준화된 AUTOSAR 포맷에 따르는 인터페이스의 설명은 어떠한 경쟁에 민감한 내부 설계를 노출하지 않아도 되는 개발 과정을 위한 입력으로 사용된다.방법론AUTOSAR Meta 모델은 AUTOSAR로 자체에 포함되어 있는 시스템을 설명하는데 사용되는 개념을 명확히 정의한다. Meta 모델의 직접적인 유도는 처음부터 일관된 포맷의 (XML ‘템플릿’에 기반한) 교환 체제이다. AUTOSAR 방법론은 시스템 개발의 모든 주된 단계로 다음과 같은 입력 설정을 포함한다.- 소프트웨어 부분- ECU 리소스- 시스템의 구속력실행할 수 있는 코드의 발생에 대하여 모든 개발 단계는 이들 단계에 대한 교환 포맷과 작업 방법을 정의하여 AUTOSAR 방법 이론으로 지원된다. AUTOSAR 방법 이론은 그 자체가 완전한 공정 설명은 아니며 분담된 개발 과정에 대한 기본으로 적용할 수 있다. 기술적인 인터페이스 호환성의 이점을 고려하여 AUTOSAR 방법론을 공동 비즈니스 형식으로 적용할 때 시너지와 개선 효과를 가능하게 할 수 있다.개발을 위한 준비AUTOSAR 표준의 개발 준비를 위하여 AUTOSAR 개발 위원회는 기술적인 절차 가이드 라인을 설정했다.표준의 정비더 많은 개발과 개선을 고려하고, 표준화의 수준을 안전하게 유지하기 위해, 표준 관리 절차의 통제는 필수적이다. 표준 유지의 주된 요소는 규격의 변경 관리와 발행 관리 등이다.- 규격의 변경 관리현재, 변경 사항은 대부분 유효한 활동을 통해 얻은 결과에서 나온다. 변경 담당자는 변화를 요구하는(Request for Charge-RfG) 변경 발의자를 위한 다이렉트 인터페이스이며, RfC의 발전을 위한 정보를 제공한다.내부적으로는 변경 조정 기구가 심의하고, 타당한 방법으로 RfC의 승인을 받는다. 필요에 따라서 전문가의 평가가 요구되기도 한다. 표준이 개발, 실행, 통합 그리고 테스트 되는 동안, 단순한 변경이나 복수의 연관된 변경 사항의 수준에 따라 품질 보증의 일환으로 사용할 수도 있다.- 규격의 발행 관리변경 관리와 밀접한 일치화에서 발행 관리는 발행 숫자와 계획과 함께 표준의 앞으로 새로운 발행에 대해 사전 예고와 애플리케이션 노트를 포함한다. 어떤 AUTOSAR 발행도 최근에 발행한 내용이 중복되지 않도록 기간을 설정하여 관리하고, 적시에 AUTOSAR 공동체와 의견을 교환하는 것이 발행 관리의 주된 특성이다.적합성 시험AUTOSAR 표준에 의거해 개발한 자동차 제품의 공급자는 적합성 시험 절차를 성공적으로 완성함으로써 이들 표준의 적합성을 증명할 수 있다. 여러 구매자들을 위한 품질 표시는 적합성 시험 기구(CTA)와 같은 제삼자에 의해 발행된 적합성 인증일 것이다. 시험 자체는 적합성 시험의 청원(CTS)을 고려하여 AUTOSAR 규격의 일부로써 형식적인 언어에 유효한 적합성 시험 규정을 실행할 것이다. 애플리케이션 계층의 소프트웨어 내부는 AUTOSAR 표준 범위 밖의 사항이며 더욱 낮은 단계의 인터페이스를 지정하는 것만으로 제한한다. 통신에서 애플리케이션 계층 소프트웨어를 위한 적합성 규격은 먼저 소프트웨어 부분의 설명과 관련이 있다. 인프라스트럭처 수준에서, 여러 시험 방법들은 복잡하지 않아야 한다. 이것은 적합성 등급의 도입으로 해결한다. 어떤 기존의 자동차 제품에 대해 테스트 그룹/경우의 관련된 세트는 다음 두 가지의 실제 결합으로 정하여 진다.- 적합성 등급의 실현(ICC)ICCx는 패키징 모듈의 표준화 방법으로 제공한다.- 기능상 적합성 등급(FCC)FCC는 기능적 동작에 초점을 맞춰 필수적이고 선택적인 특성을 구분한다.AUTOSAR로 이전연속적으로 개발한 AUTOSAR 표준의 도입은 단번에 이루어지지 않을 것이다. 대신 기존의 항목을 안전하게 유지하고 자동차의 발달 주기에 동기화하며 위험도를 최소화 함으로써 주어진 개발 내용에서 도입을 계획하고 성숙되도록 통제하는 것이 바람직 할 것이다.이를 고려하여 AUTOSAR 개발 파트너십을 독점 소프트웨어부터 타당한 전이단계를 거친 중간 과정을 통한 모든 AUTOSAR에 적합한 아키텍처까지 표준 개발 초기 단계에서 계획된 변화에 합의했다.이런 변화 방법의 하측은 결과적으로 얻은 미들 아키텍처가 여전히 독점적인 해법이라는 것으로, 예를 들면 적합성 시험 방법을 적용할 수 없거나 부분적으로만 적용된다는 것이 그 예이다. 더욱 유연하게 이전하는 다른 방법은 ICC1의 정의에 의한 것이다. 이것은 인프라 수준과 함께 inter-ECU 수준으로 하는 것이 사실이다. 실제로 양측 방법은 연관성이 있다. ECU는 내부에서, ICC1는 초기 이전 단계에서 사용할 수 있다.다만 소프트웨어 구성과 버스 커뮤니케이션으로 주어진 애플리케이션 계층 인터페이스에 대해 표준화 호환성이 요구된다. 뿐만 아니라 이것은 이미 모든 기능 소자의 충분한 재사용과 전달 능력을 보유하고 있다.그러나 여전히 전체 AUTOSAR 아키텍처(ICC/2/3)로 옮겨가야 한다. 그렇지 않으면 표준화된 소프트웨어 인프라스트럭처의 모든 장점을 사용할 수 없다.통신과 네트워크 관리 기구의 호환성으로 인해 ECU에 따른 ICC1은 네트워크 시스템에서 더욱 높은 적합성 등급에 접속할 수 있다.끝으로 ICC1은 기본 소프트웨어 실행의 동작을 일부 확장된 종합 디바이스 드라이버(CDD)에 따르도록 한다. 역 논리로 CDD는 이전 기구와 비슷하게 사용할 수 있다. CDD를 다른 목적용으로 설계된 사실에도 불구하고 이 개념은 리엔지니어링을 위한 일시적인 필요 없이 현재의 실행에 이전하기 위해 사용 가능하다.툴링(TOOLING)강력한 툴의 가능성은 AUTOSAR 표준의 개발에서 매우 중요한 성공의 열쇠가 된다. 이런 툴의 규격은 AUTOSAR 개발 위원회 범위 밖의 일이다. 그러나 AUTOSAR 방법 이론에서 여러 가지 단계를 위해 정의된, 명확한 교환 포맷은 심리스한 툴 체인을 효율적으로 가능하게 한다. AUTOSAR 규격 제정에 병행하여 기여하면서 다양한 툴 공급자들이 현재 적당한 툴의 해답을 준비하고 있다.맺는 말AUTOSAR 개발 위원회는 상용 개발을 목적으로 한, 강화된 스펙 준비의 최종 단계에 있으며, 모든 AUTOSAR 회원사는 발행 표준과 자유 경쟁의 시장에 따라 자동차 애플리케이션 개발에 이 표준을 사용할 수 있다. 일련의 개발을 위한 표준 규격의 성숙도는 두 가지 프로토타입 실현과 유효한 단계를 통해 효과적으로 안정화되고 있다.게다가 조정된 적용을 따른 표준 유지의 절차 및 적합성 시험을 위한 지원은 자동차 E/E 애플리케이션을 위한 표준의 유용성을 안정화시킬 것이다. 표준화된 소프트웨어 인프라스트럭처와 표준 AUTOSAR 설계 기술 요소는 주목할만한 장점이다. 게다가 AUTOSAR 방법은 미래 멀티 발전 프로세스의 효율과 효과에 있어서 이익을 가능하게 할 수 있는데다, 심리스한 연결에 있어서 툴의 능력에 의한 가능성을 가지고 있다.모든 현재의 회원과 새로운 전망들이, 성과를 만들고 AUTOSAR 단계 2의 계속되는 발전에 공헌하기 위해 모이고 있다.

회원가입 후 이용바랍니다.

개의 댓글

회원로그인

작성자 비밀번호

댓글 내용입력

댓글 정렬

최신순 추천순 답글순

BEST댓글

BEST 댓글 답글과 추천수를 합산하여 자동으로 노출됩니다. 닫기

더보기

신용진 (webmaster@techworld.co.kr)

기자의 다른기사 보기

저작권자 © 테크월드뉴스 무단전재 및 재배포 금지