Software detailed design & unit verification in the model based development(모델 기반 개발 환경/프로세스에서 SW단위설계와 단위테스트 활동) : A-SPICE & ISO 26262에서의 적용

 

● 프로세스 측면

ISO 26262-6: 2018에 의하면 소프트웨어의 Safety requirements와 Non-safety requirements는 하나의 개발 프로세스 (one development process)에 의해 취급되어야 한다고 정의하고 있다. 왜냐하면 하나의 소프트웨어는 safety related requirements와 non-safety related requirement를 포함하고 있기 때문이다. 즉 SSR(SW Safety Requirements)만을 SRS(Software Requirements Specification)로 간주하여 관리 및 작성하면 안된다. 일부 현장에서는 개발 상의 리소스 및 오해의 소지로 이러한 경우가 종종 발생하고 있다. 하지만 명확한(clear), 정확한(correct), 모호하지 않은(unambiguous), 검증가능한(verifiable), 추적가능한(traceable) 요구사항이 되기 위해서는 이러한 실수를 범하지 않는 것이 좋다.

그리고, 소프트웨어 개발 방법 및 환경(예, MBD, Manual, Agile 등)에 대한 정의는 반드시 개발 계획서(또는 프로젝트 계획서 및 안전 계획서)에 explicitly 명시되어야 한다.

● 엔지니어링 측면

MBD(Model Based Development)를 적용하여 개발하는 경우 auto code generation에 해당하는 모델을 SW Unit의 단위로 정의 및 적용하는 것이 바람직하다.

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

또한 Model level에서 verification은 소스 코드에서의 verification을 대체할 수 있다. 단, 생성된 코드(generated source code)가 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-6;2018]

 그리고 model based development에서는 ISO 26262-6에서 제시하고 있는 “Design principles for SW unit design and implementation” 중 아래 사항들은 필수적으로 적용되어야 하는 사항이 아니라고 가이드 하고 있다.

• 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 등, 아래 표 참조)을 적용하는 것이 요구된다. 위에서 필수적으로 적용해야 되지 않더라도, 자체 모델링 가이드 라인에서 위의 Design guideline을 요구하면, 모델링 가이드 라인에 우선하여 적용한다.

구분	내용
MAAB	Modeling guidelines of Mathworks Automotive Advisory Board
MISRA AC GMG	MISRA Generic modelling design and style guidelines
MISRA AC SLSF	Modelling design and style guidelines for the application of Simulink and Stateflow
MISRA AC TL	Modelling style guidelines for the application of TargetLink
DSPACE MG	DSPACE model guidelines for Targetlink

위의 모델링 가이드는 다양한 기준에서 적용을 하고 있지만, 모든 가이드 라인을 적용할 필요는 없으며, 자사의 개발 환경 및 제품의 상황(context)에 맞게 선정 또는 수정하여 정의한다.

 만약 코드 생성을 위해 사용된 모델들(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를 수행해야 하며, 그 수행결과가 기능 및 비 기능 요구사항을 충분히 만족하고 있다는 증거를 제시해야 한다.

 아래 사항은 ASPICE에서 모델기반 개발에서의 검증활동에 대한 평가 기준이다.

1)    단위 소프트웨어가 검증된 모델(Verified model)로부터 생성되고, 그 해당 소스코드(소프트웨어 : 코스 생성 이후에 수정되지 않을 경우)에 대해 정적 검증(Statically verified)이 수행되지 않는다고 해서, SWE.4 BP3를 Downrate 하지 않아야 한다. 단, ISO 26262-6에서와 같이 코드 생성기가 충분히 신뢰성이 있다는 가정이 필요하다.

2)    단위 소프트웨어가 검증된 모델(Verified model)로부터 생성되고, 그 해당 소스코드 (소프트웨어 : 코스 생성 이후에 수정되지 않을 경우)에 대해 테스트(test)되지 않았다고 해서, SWE.4 BP4 downrate 하지 않아야 한다. 단, 마찬가지로 코드생성기에 대한 신뢰성이 요구된다.

3)    단위 소프트웨어가 검증된 모델로부터 생성된 후, 그 소프트웨어가 일부 수정이 발생한다면 반드시 명시적으로 정적 검증과 테스트(Statically verified and tested)가 수행되어야 한다.  [Automotive SPICE Guideline]

/SWE.4 BP3/ : Perform static verification of software units.

/SWE.3 BP4/ : Evaluate software detailed design.

 또한 소프트웨어 단위 테스트의 완전성(Completeness) 및 충분성(adequate)의 측면에서 제시되어야 하는 증거(evidence)로 구조 커버리지(Structural coverage)의 결과를 제시해야 한다.

이러한 경우, ISO 26262-6: 2018에서는 model development process의 환경에서 소소코드를 생성하는 경우, 구조 커버리지의 분석을 모델레벨에서 수행할 수 있다고 설명하고 있다. 또한 그 수행결과를 소소코드의 커버리지 메트릭의 결과 대신에 사용할 수 있다는 예시를 들어 설명하고 있다.

결론적으로 model based development를 적용하는 경우, Unit testing에 대한 부분은

1)    모델에 대한 Verification을 반드시 실시해야 하며, 첫번째 모델링 가이드를 준수했는지를 검증하고 두번째, 개별 모델들이 소프트웨어의 사양 및 아키텍처와 Consistency를 가지고 있는지 검증해야 한다.

2)    만약 코드 생성기가 충분한 신뢰성을 가지고 있고, 모델기반 개발에서 검증된 모델에서 코드를 자동생성을 통해 개발한다면, 코드 레벨의 MISRA 가이드와 같은 검증은 생략할 수 있다. (하지만 현재 일부 OEM과 Tier는 모델기반 개발이더라도, MISRA 검증을 요구하고 있는 것이 현실이다.)

3)    모델기반 개발의 경우, ASIL C와 D인 경우는 반드시 SIL(if applicable, HIL)과 같은 Back-to-back 환경에서 모델과 코드의 일치성을 검증해야 한다.

4)    마지막으로 Unit testing에서 ISO 26262:2018나, ASPICE Guideline에서는 모델기반에서 구조 커버리지 상응하는 신뢰성 있는 측정결과와 테스트 결과가 SW 기능 및 비기능 요구사항을 충분히 준수하고(Compliance)있다는 증거를 제시할 수 있다면, 소스코드 레벨에서 단위 테스트 및 커버리지 측정에 대한 증거 제시는 생략이 가능하다. (하지만 이부분도 일부 OEM과 Tier에서 모델기반 개발이더라도, 코드 레벨의 단위 테스트 및 커버리지 측정 결과를 요구하고 있는 것이 현실이다.)

사실 모델 기반 개발에서 모델 단위의 검증(verification and test)와 커버리지 측정을 완료 한 후, 또 코드레벨에서 반복적인 활동을 수행한다면 많은 리소스의 낭비 및 개발시간/비용이 매우 증가할 수 있으므로, 이러한 부분은 지양하는 것이 바람직하다.

 참고로, 커버리지 기준에 대한 요구사항은 아래와 같이 요약 할 수 있다.

여하튼 일반적으로 70%~80%가 적정선으로 연구된 논문들이 많다. Empirical Study와 같은 실증적인 논문들에 대한 제안(Proposal)이긴 하지만, 이러한 제안(Proposal)도 사실 몇 가지 제안된 실험을 통해 제안하고 있다. 그러나, 80%이상의 커버리지를 달성하기 위해서 실제 투입되는 테스트 공수(Testing Costs)대비 산출되는 효과는 작아진다는 것(비용대비 효과의 곡선 참조)이 산업계 및 학계의 정설이다.

즉 80%~90%이상의 커버리지를 달성하기 위해서 소요되는 테스트케이스 개발, Driver 및 Stub 개발, 테스트 수행 및 분석/리포터 비용이 상상을 초월한다는 의미하다.

 

하지만 일부 고객들 중에서 커버리지 100%가 되어야 한다고 요구를 하고 있다. 이러한 부분은 실제 개발 및 테스트 활동 중, 특히 시스템 아키텍처, 소프트웨어 설계서(아키텍처, 단위 설계서 등), 시뮬레이션 검증 및 실차 테스트에 리소스를 더 투입하는 것이 비용 대비 효과가 더 높기 때문에, 단위 테스트의 커버리지 강도 즉, 100%의 요구를 지양하는 것이 바람직하다.