개발

jackryu 2011. 8. 21. 11:58

 

<자동차 산업의 안전성 관련 현황>

- 자동차의 소프트웨어 기반 기능 사항들이 증가하고 있고 그것은 더욱 더 복잡해져 가고 있다.

- 자동차의 새로운 기능들은 대부분 안전성과 관련이 있다.

 

<소프트웨어 기반 자동차 기능 개발에 관련한 현황과 미래 상황>

- 독일 입법부에서는 안전한 자동차는 최신 기술을 따라 개발되도록 요구하고 있음

- IEC 61508에 기반하여, 새로운 표준인 ISO 26262는 자가용의 EE 시스템의 특정한 어플리케이션 분야의 요구를 따르기 위해 도출되었다.

- 2011년 ISO 표준이 제정되면, 새로운 표준은 모든 자동차 개발 플랫폼에 적용될 것이다.

- 추가적인 개발 요구사항과 프로세스 지원은 safety management, document management등을 만족하여야 하며,

hazard analysis and risk assessment, safety analysis methods등과 같은 적절한 메소드가 적용되어야 한다.

 

<ISO 26262의 목표>

- 각각의 자동차 기능에 대해 잠재적인 리스크와 독립적인 허용되는 잔여 리스크를 성취하는 것

- 안전성 관련 시스템의 개발에 대한 최신 기술은 다음을 이야기 한다:

- 시스템 fault의 예방

- 남아있는 관련 fault/failures를 탐지, 조절, 다룸

- E/E 시스템의 기능적 안정성을 성취할 수 있는 필요한 모든 활동들을 정의함

- 다시 말해, 자동차에 있는 잠재적인 리스크를 식별화 하고, 수용 가능한 리스크 목표를 정의하고 안전성

요구사항을 수립한다. 또한 리스크를 피하거나 줄이기 위한 척도를 정의하고 구현한다. 마지막으로 안전성

목표가 만족되는지 validate한다.

 

<자동차 안전 무결성 수준>

- ASIL A, B, C, D 네 가지로 분류된다.

- 중요한 사항: ASIL은 항상 구체적인 안전성 요구사항을 참조한다.

 

<ISO26262의 오버뷰 (axeldold.pdf 파일의 페이지 7)>

 

<Challenges>

- 메소드&프로시져, 툴: 어떤 ㅍ로시져, 메소드, 도구가 더 적용되어야 하는지? 그리고 이러한 메소드,

도구들이 어떤 새로운 프로세스를 요구하는지?

- 개발 프로세스: ISOS26262를 달성하기 위해서 무엇이 바뀌어야 하는지?

 

*** SIL(sAFTEY iNTEGRITY LEVELS)은 IEC 61508부터 제시된 중요한 요소이다. 레벨은 1~4이며, 4의 경우 더욱 신뢰성이 높다.

*** ASIL(Automotive SIL)은 A~D 단계까지 있으며, SIL과 1:1로 대응되지 않는다. 예를 들어 C는 SIL2~3에 대응되며, D는 SIL4에 대응된다.

 

 

- ISO 26262는 총 10개의 파트로 구성되어 있다.

- 파트3~6는 컨셉부터 시스템 레벨까지의 개발 프로세스를 커버한다. 파트 5와 6는 각각 하드웨어와 소프트웨어와 관련된 내용을 커버한다.

- 하드웨어와 소프트웨어 개발 모두 V모델을 따른다.

- 소프트웨어 개발 phase: 소프트웨어 안전 요구사항 명세화->아키텍쳐 디자인->유닛디자인/구현->유닛테스팅->통합및테스팅->소프트웨어 안전 요구 사항 검증 (verification)

    -> 각 phase마다 목표, general, input, requirement, recommendations, work product가 정의되어 있음

    -> 예:

5.4.8: The criteria to be considered when selecting a suitable modeling or programming language are:

a) an unambiguous definition; Example syntax and semantics of the language

b) the support for embedded real time software and runtime error handling; and

c) the support for modularity, abstraction and structured constructs.

• Criteria that are not sufficiently addressed by the language itself shall be covered by the corresponding guidelines, or by the development environment.

• Note 1: The selected programming language (such as Ada, C, C++, Java, Assembler or a graphical modeling language) is to fulfill the criteria given in 5.4.6. Usually programming or modeling guidelines are necessary to fulfill these criteria.

• Note 2: Assembly languages can only be used for those parts of the software where the use of high-level programming languages is not appropriate. Examples are low-level software with interfaces to the hardware, interrupt handlers and time-critical algorithms.

 

<Automotive spice>

우선 ASPICE의 전신인 SPICE에 대해서 간략하게 알아보도록 한다. SPICE(Software Process Improvement and Capability Evaluation)은 ISO와 IEC에 의해 개발된 "프로세스 평가 프레임워크"이다. 이 프레임워크는 CMM을 비롯한 여러 모델과 표준으로부터 도입되었다. SPICE는 초기에 소프트웨어 개발 프로세스에만 적용되었지만, 이것이 확장되어 조직/관리/엔지니어링/제조 등 다양한 분야에 적용될 수 있게 되었다. 이 프레임워크를 이용하여 5가지로 프로세스 수준을 평가할 수 있고, 이를 평가하기 위한 프로세스의 속성으로는 9가지가 존재한다.

ASPICE는 SPICE로부터 도출된 것으로, 유럽의 자동차 시장에 의해 개발되었다. ASPICE의 목적은 공급자들을 평가하기 위한 SPICE와 호환되는 표준 요구사항을 만드는 것이었다. 이를 위해서 21개의 프로세스가 제거되었고 5개의 프로세스가 추가되었다.

ASPCIE가 ISO 26262와 갖는 차이점은 다음과 같다:

  1. ASPICE가 소프트웨어와 시스템 개발에 초점을 맞췄다면, ISO 26262는 안전과 관련되어 있는 시스템 개발에 중점을 두었다.
  2. ASPICE가 프로세스의 성숙된 certificate로 결과가 나온다면, ISO 26262는 expertise로 나온다.
  3. ASPICE의 목적은 효율적이고 반복적인 개발인 반면, ISO 26262는 리스크를 계산할 수 있는 프로덕트를 개발하는 것이다.
  4. ASPICE의 동기는 결국 이익이지만, ISO 26262는 법적 책임과 관련되어 있다.
  5. ASPICE의 목표는 비즈니스의 목표와 관련되어 있는 반면, ISO 26262는 위험 분석과 관련되어 있다.
  6. ASPICE는 구체적인 메소드를 요구하지 않지만, ISO 26262는 how를 요구한다.

 

 

 

 

 

Autosar(Automotive Open System Architecture): software infrastructure를 제공한다. 공통의 소프트웨어 인프라를 제공 (표준 인터페이스, 소프트웨어와 시스템의 모듈화, 측량 가능, 재사용 가능하게 만듦. 이를 이용하여 실행 환경에 대한 인터페이스를 정의하여, 어플리케이션과 하드웨어의 커플링을 줄이고 이로서 소프트웨어가 다른 하드웨어로 이식되거나 업그레이드 되는 것이 용이해 질 수 있다. 또한 Autosar는 26262에서 정의된 방법론과 쉽게 매핑되는 개발 방법론을 가정한다. 이것은 기본 시스템 기능, 다른 자동차와 플랫폼을 측량하는 방법, 네트워크 상에서의 전송 방법, 다수의 공급자로부터의 통합, 제품의 유지보수에 관한 표준을 포함한다.

AUTOSAR은 컴포넌트 기반 소프트웨어 디자인의 사용을 가능하게 한다. 이러한 컴포넌트들은 기능 단위로서 구성된다. 따라서 여러 어플리케이션이 독립되어 존재할 수 있고, AUTOSAR은 이러한 어플리케이션 간에 표준 인터페이스를 제공하여 서로간의 통신을 돕는다.

AUTOSAR은 컴포넌트 기반 디자인을 가능하게 하기 위하여, 하드웨어와 소프트웨어 서비스를 돕는 기능성의 분리를 위해 레이어 기반 아키텍처를 사용한다:

  • 기본 소프트웨어 레이어: 기본 소프트웨어는 아무런 기능도 가지지 않지만 하드웨어 의존적이거나 의존적이지 않은 서비스를 상위 레이어(Runtime Environment)에 제공하는 역할을 하는 표준 소프트웨어이다. 일종의 API라고 할 수 있다.
  • 실행 환경: 소프트웨어 컴포넌트들과 하드웨어 간의 정보 전달을 처리한다.
  • Application Layer: 실제 기능들이 수행되는 레이어. 여러 어플리케이션 컴포넌트로 구성되어 있고, runtime environment를 통해서 통신한다.
이런 정보 정말 대단히 감사합니다!