Skip to main content

MBD 개발 프로세스에서 SW 단위 설계와 단위 검증 전략

차량 소프트웨어를 MBD1) 개발방법을 적용함에 있어서, Automotive SPICE®와 ISO 26262의 요구사항들을 만족해야 합니다.

이러한 요구사항들은 소프트웨어의  개발 단계 (예, SW 요구사항 단계, SW 아키텍처 설계 단계, SW 상세 설계 단계 등) 전체 에서 적용이 가능하나, 일반적으로 “SW 상세 설계 단계”에 적용하는 것이 현실적이고, 위의 표준 요구사항들을 만족하는데 어려움이 적습니다.

물론 SW 요구사항이나 아키텍처 설계 단계에서 적용하는 것도 가능하나, 개발 프로세스내에서 적용되는 모델링 방법이나,

모델링에 대한 기준을 명확하게 마련하는 것은 쉽지가 않습니다. 이러한 이유로 해외의 많은 부품사들은 SW 상세 설계 단계에서 MBD를 적용하는 것이 추세입이다.

주1) MBD : Model Based Development

MBD in SW Development Process (Automotive SPICE® & ISO 26262)

SW개발 단계에서 MBD의 적용은 2가지 측면이 고려되어야 합니다. 첫번째는 “프로세스 측면(Process Aspect)”과 두번째는 “엔지니어링 측면(Engineering Aspect)”에서 MBD적용에 대한 부분을 고려해야 합니다. 아래 그림은 MBD의 전형적인 개발 프로세스 및 검증 환경에 대한 예입니다.

① 프로세스 측면

ISO 26262-6: 2018에 의하면 소프트웨어의 Safety requirements와 Non-safety requirements는 하나의 개발 프로세스 (one development process)에 의해 취급되어야 한다고 요구하고 있습니다. 왜냐하면 하나의 소프트웨어는 safety related requirements와 non-safety related requirement를 포함하고 있기 때문입니다.

즉 SW Safety Requirements만을 Software Requirements Specification로 간주하여 요구사항을 정의하면 안된다고 요구하고 있습니다. 그리고, MBD, Agile, Manual 코딩 등 소프트웨어 개발 방법 및 환경에 대한 정의는 반드시 개발 계획서(또는 프로젝트 계획서 및 안전 계획서)에 명시적으로(explicitly) 정의해야 합니다.

② 엔지니어링 측면 (설계)

MBD를 적용하여 개발하는 경우 auto code generation에 해당하는 모델을 SW 상세 설계레벨에서 정의하여 코드와 추적이 가능하도록 적용하는 것이 바람직합니다.

그리고, MBD에서 모델들이 code generation 에 사용되는 경우, 반드시 모델에 대한 Verification이 수행되어야 합니다. [Automotive SPICE Guideline]

또한 Model level에서 verification은 소스 코드에서의 Verification을 대체할 수 있습니다. 단, 생성된 코드(code generation)가 SW 기능의 속성(properties)을 유지한다는 가정에서 가능하다는 의미입니다. (즉, 코드 생성기가 충분히 신뢰할 만하다면) [ISO 26262-6 : 2018]

SW Unit design에서 “Consistency and integrity of the interface”의 의미는 상위 요구사항(예, 아키텍처 및 요구사양서 등)과의 일관성, 정확성 등을 의미하며, ASPICE는 이러한 부분은 Review 또는 verification를 통해 확인이 가능합니다. [ASPICE, Traceability and consistency 참조]

SW Unit design에서 “Robustness”의 의미는 error detection과 error handling에 대한 충분한 mechanism을 가지고 있을 때 가능하고, Review나 테스트를 통해 확인이 가능합니다.

그리고 ISO 26262의 Part 6에서 제시하고 있는 “Design principles for SW unit design and implementation” 중 아래 사항들은 MBD개발 시, 모든 항목들이 반드시 적용되어야 하는 사항은 아닙니다.

  • One entry and one exit point in subprograms and functions
  • No dynamic objects or variables, or else online test during their creation
  • No multiple use of variable names
  • Avoid global variables or else justify their usage
  • Restricted use of pointers
  • No implicit type conversions
  • No unconditional jumps

하지만, Model 설계를 적용하는 경우 모델링 가이드 라인 (예, MAAB, MISRA 등, 아래 표 참조)을 반드시 적용하는 것이 요구됩니다. 위에서 필수적으로 적용해야 되지 않더라도, 자체 모델링 가이드 라인에서 제시하는 요구사항들이 ISO 26262 Part 6에서 요구하는 Design guideline의 기준이 있다면 모델링 가이드 라인에 우선하여 적용을 할 수 있습니다.

MBD 적용에 있어서 Verification의 적용 기준

A-SPICE에서 만약 코드 생성을 위해 사용된 모델들(models)에 대한 검증(static verification) 및 테스트(test)가 단위설계(단위 유닛)에 대한 Compliance에 대한 충분한 증거를 제공하지 못한다면 SWE.4 BP3(Perform static verification of software units)는 약점을 가지고 있습니다.

또한 SWE.3 BP4(Evaluate software detailed design)도 더불어 등급이 낮게 판정 됩니다..[Automotive SPICE Guideline]

즉, 코드생성을 위한 모델은 모델 자체에 대해 반드시, Verification 및 Test를 수행해야 하며, 그 수행결과가 기능 및 비 기능 요구사항을 충분히 만족하고 있다는 증거를 제시해야 합니다. →모델 자체에 대한 충분한 검증에 대한 증거(예, 모델 리뷰, 모델 시뮬레이션)의 확보가 필요합니다.

A-SPICE SWE.3에서 요구하는 직접적인 검증활동(SWE.4, BP3, BP4)에 대해 모델기반 개발(MBD)를 적용시 검증활동에 대한 판정하는 기준입니다.

SWE.4 BP3 : Perform static verification of software units, SWE.3 BP4 : Evaluate software detailed design.

  •  단위 소프트웨어가 검증된 모델(Verified model)로부터 생성되고, 그 해당 소스코드(코스 생성 이후에 수정되지 않을 경우)에 대해 정적 검증(Statically verified)이 수행되지 않는다고 해서, SWE.4 BP3를 낮게 판정하지 않아야 합니다. 단, ISO 26262-6에서와 같이 코드 생성기가 충분히 신뢰성이 있다는 전제조건이 필요하고, 코드로 생성한 모델들이 사전에 충분한 검증이 수행되어야 합니다.
  • 단위 소프트웨어가 검증된 모델(Verified model)로부터 생성되고, 그 해당 소스코드(코스 생성 이후에 수정되지 않을 경우)에 대해 단위 테스트(Test)가 되지 않았다고 해서,  SWE.4 BP4 를 낮게 판정하지 않아야 합니다. 단, 마찬가지로 코드생성기에 대한 신뢰성이 요구되고, 코드로 생성한 모델들이 사전에 충분한 검증이 수행되어야 합니다.
  • 단위 소프트웨어가 검증된 모델로부터 생성된 후, 그 소프트웨어가 일부 수정이 발생한다면 반드시 명시적으로 정적 검증과 단위 테스트(Statically verified and unit tested)가  수행되어야 합니다.  [Automotive SPICE Guideline & PAM 3.1]

[Conclusions]

  1.  SW상세 설계 단계에서 모델에 대한 Verification을 반드시 수행해야 하며, 이는 첫째, 모델링 가이드를 준수했는지를 검증하고 둘째, 개별 모델들이 소프트웨어의 사양 및  아키텍처와 Consistency를 가지고 있는지 검증해야 합니다. Consistency의 검증 방법은 모델 리뷰, MIL(Model In the Loop)등의 방법 등이 있을 수 있습니다.
  2.  만약 코드 생성기가 충분한 신뢰성을 가지고 있고, 모델기반 개발에서 검증된 모델의 자동생성을 통해 개발 및 가이드 라인을 적용 한다면, 코드 레벨의 정적 검증은  생략할 수 있습니다. (하지만 현재 많은 OEM과 Tier는 모델기반 개발이더라도, 코드 레벨에서 정적 검증을 추가로 요구하고 있는 것 또한 현실입이다.)
  3.  모델기반 개발의 경우, ASIL C와 D인 경우는 반드시 SIL(if applicable, HIL)과 같은 Back-to-back 환경에서 모델과 코드의 일치성을 검증해야 합니다.
  4.  마지막으로 Unit testing에서 ISO 26262:2018나, A-SPICE Guideline에서는 모델기반에서 구조 준수(Compliance)하고 있다는 증거를 제시할 수 있다면, 소스코드 레벨에서  단위 테스트 및 커버리지 커버리지 상응하는 신뢰성 있는 측정결과와 테스트 결과가 SW 기능 및 비기능 요구사항을 충분히 측정에 대한 증거 제시는 생략이 가능합니다. (하지만 이부분도 일부 OEM 및 Tier들이 모델기반 개발이더라도, 코드 레벨의 단위 테스트 및 커버리지 측정 결과를 추가로 요구하고 있는 것이 현실입니다.)
목록