안전성 준수 시스템의 임베디드 소프트웨어 테스트 모범 사례

개요

규제 표준은 복잡한 고보증 어플리케이션에서 더욱 중요합니다. 이러한 표준 중 일부는 수년 동안 자리를 잡은 것인 반면, 일부는 현재 주요 산업에서 대두되고 있는 것입니다. 많은 표준이 특정 산업의 요구사항에 맞춰져 있지만, 규정 준수를 입증하는 데는 모두 유사한 개발 프로세스의 적용이 필요합니다. 동시에 이러한 기능 안전 표준은 안전이 필수적인 전자 부품을 개발하는 엔지니어와 조직에게 여러 가지 과제를 제시합니다. 이러한 과제에는 필요한 문서 및 자료를 추적하고, 기능적 요구사항이 시스템 수준에서 적용하도록 보장하고, 새로운 역할과 추가된 지식에 따른 조직 수준의 문제를 해결하고, 기존의 개발 프로세스 위에 새로 적용된 프로세스를 따르는 일이 포함됩니다. 그리고 이 모든 과제를 비용을 크게 증가시키지 않으면서 해결해야 합니다.

일반적으로 제품 설계에서 전반적인 프로세스 규정 준수 및 고려사항이 분석되지만, 제품 개발의 검증 측면을 잊어서는 안 됩니다. 많은 기능 안전 표준은 설계 외에 테스트를 위해 완료해야 하는 요구사항과 단계를 특별히 명시합니다. 동시에 이러한 고려사항은 개발 주기 전반에 걸쳐 수행되는 모든 검증 유형, 즉 model-in-the-loop 테스트, 신속 제어 프로토타이핑, HIL 시뮬레이션과 같은 순수 시뮬레이션 검증부터, 다이나모미터 및 환경 챔버 사용을 통한 순수한 물리적 테스트에서까지 고려되어야 합니다. 이 문서의 목표는 이러한 표준의 테스트에서 발생할 수 있는 몇 가지 과제를 요약하고 이러한 시스템 검증 비용을 최소화하기 위한 몇 가지 방법을 소개하는 것입니다.

내용

기능 안전 표준의 배경

기능 안전은 임베디드 시스템의 검증에 적용되는 프로세스 지향 안전 인증 표준입니다. 예를 들어, IEC 61508은 자동차 (ISO 26262) 및 의료 (IEC 60601) 등 다양한 산업에서 도입된 기능 안전 표준으로 항공우주 산업 (DO-178B 및 DO-254)의 안전 표준과 유사합니다. 임베디드 디바이스에 요구되는 수명 주기 프로세스 인증 외에도 많은 이러한 표준은 사용될 테스트 시스템에 대해 유사한 수명 주기 요건을 요구합니다.

제조업체는 기능 안전 실무를 제품 수명 주기에 통합하여 복잡한 시스템의 개발을 관리합니다. 이는 위험 분석, 요구사항 추적과 개발 단계 전반에서 테스트 및 코드 분석 프로세스를 문서화하여 달성됩니다. 예를 들어, ISO 26262는 테스트 프로세스의 엄격도를 결정하기 위해 자동차 안전성 레벨 (ASIL)의 수립을 요구합니다.

그림 1. 장애의 심각성, 노출도 및 제어 가능성을 알면 요구사항의 ASIL을 결정하는데 도움이 됩니다.

설계와 테스트 융합

생산자는 제품 수명 주기 초기에 부품 및 임베디드 소프트웨어 테스트를 시작하여 결함을 조기에 찾아야 하며, 이로써 전체 제품 개발 비용을 절감할 수 있습니다. 이렇게 하면 일반적으로 개발 과정의 후반에 발견되는 에러를 식별하고 해결할 수 있습니다. 최종 확인 전에 이러한 에러를 수정하면 개발 시간과 프로젝트 비용을 절약할 수 있으며 제품 리콜 확률을 줄일 수 있습니다. 제조업체는 제품 수명 주기 전반에 걸쳐 여러 테스트를 수행하여 프로세스 전반에 걸쳐 버그를 식별할 수 있습니다.

그림 2. 개발 주기 전반에 걸쳐 다양한 유형의 테스트를 수행하여 나중에 프로젝트 시간과 비용을 절감할 수 있습니다.

위의 그림은 개발 과정의 여러 부분에 대해 권장되는 테스트 방법을 보여주는 소프트웨어 개발 주기를 나타냅니다. HIL (Hardware-in-the-Loop) 및 Model-in-the-Loop 테스트와 같은 방법은 다양한 안전 표준에서 권장 테스트 방법으로 명시됩니다.  

재구성 가능한 플랫폼을 사용하면 생산자가 개발 단계 전반에 걸쳐 다양한 테스트를 사용자 정의하고 여러 어플리케이션에서 구성요소를 재사용할 수 있습니다. 구성요소를 재사용하면 제조업체가 인증된 테스트 시스템의 구성요소를 대규모 어플리케이션의 구성요소로 사용할 수 있으므로 시간과 비용을 절약할 수 있습니다.

그림 3.  일반적인 테스트 구성요소는 제품 개발 전반의 다양한 테스트 단계에서 재사용될 수 있습니다.

 

개발 과정에서 테스트 요구사항이 변경되므로 생산자는 이러한 변경사항을 관리하고 요구사항을 충족하도록 테스트를 다시 설정할 수 있는 플랫폼이 필요합니다. 예를 들어, ISO 26262에 따라 테스트하는 자동차 제조업체는 ECU 테스트 시스템의 일부를 여러 자동차에서 재사용할 수 있습니다. 이러한 구성요소는 개발 단계 전반에 걸쳐 있으며 모델, 자극 프로파일, 사용자 인터페이스 및 데이터 로깅을 포함합니다.

그림 4.  테스트 구성요소는 매우 다양하며 프로젝트의 여러 부분을 구성합니다.

NI의 도구는 기능 안전 테스트를 수행하기 위한 표준화된 테스트 시스템을 개발하는데 이상적입니다. NI는 생산자가 기능 안전 요구사항을 충족하는 테스트 어플리케이션을 신속하게 개발할 수 있게 하는 하드웨어 및 소프트웨어 통합 플랫폼을 제공합니다. NI는 모듈형 하드웨어 플랫폼을 제공하기 때문에, 유사한 테스트 어플리케이션을 더 작거나 보다 정교한 임베디드 시스템의 테스트 요구사항에 맞게 조절할 수 있습니다. NI는 생산자가 설계 프로세스 전체에서 구성요소를 테스트할 수 있는 소프트웨어 정의된 재구성 가능한 플랫폼을 제공합니다.

LabVIEW, LabWindows/CVI, NI VeriStand, NI Requirements Gateway, NI TestStand와 같은 소프트웨어 도구는 자동 테스트 산업에서 광범위하게 사용됩니다. 이러한 소프트웨어 도구를 사용하면 PXI 시스템과 같은 하드웨어 제품과 쉽게 연결하고 모듈형 테스트 어플리케이션을 설정할 수 있습니다. 컨트롤러 및 다양한 I/O 모듈과 함께 연결된 PXI 시스템을 사용하면 단일 플랫폼에서 다양한 구성요소를 테스트할 수 있습니다. 테스트 요구사항이 변경될 때, 생산자는 타사 개발자가 새로운 테스트를 위해 시스템을 다시 설정하는 것보다 더 낮은 개발 비용으로 모듈을 추가하고 소프트웨어 프로그램을 수정할 수 있습니다.

DO-178B 및 기타 안전 표준은 HIL과 같은 테스트 방법을 특별히 권장합니다. NI HIL 플랫폼은 다양한 유형, 가치를 제공하며 쉽게 구매할 수 있는 많은 제품과 함께 개방형 하드웨어 및 소프트웨어 플랫폼을 제공합니다. 다음은 NI가 테스트 어플리케이션을 위해 제공하는 몇 가지 하드웨어 제품입니다.

  • 아날로그 및 디지털 I/O용 다기능 데이터 수집 모듈과 CAN, LIN, FlexRay, MIL-STD-1553 및 ARINC 429와 같은 네트워크를 위한 버스 고성능 인터페이스
  • 전자 테스트 시스템에서 개방과 단락을 시뮬레이션하는 오류 삽입 유닛
  • 하드웨어 I/O, 데이터 로깅, 자극 생성 및 모델 실행의 결정성 있는 실행을 위한 리얼타임 프로세서
  • 보다 강력하고 유연한 테스트 시스템을 위한 사용자 프로그래밍 가능 FPGA 포함 재구성 가능한 I/O (RIO).

NI는 위 모든 하드웨어 제품을 PXI 폼 팩터로 제공하여 임베디드 컨트롤러가 여러 섀시에서 모듈과 통신하고 동기화할 수 있습니다. 리얼타임 PXI 컨트롤러는 NI Requirements Gateway, NI VeriStand, NI TestStand와 같은 소프트웨어 도구와 쉽게 상호작용하여 요구사항 추적, HIL 시뮬레이션 및 테스트 자동화를 수행할 수 있습니다. 이러한 소프트웨어 도구를 사용하면 효율적이고 비용 효과적인 방식으로 테스트 어플리케이션을 인증할 수 있으며, 여러 산업에서 기능 안전 실무에 적용할 수 있습니다.

그림 5. NI 소프트웨어 도구는 함께 동작하여 기능 안전 규정 준수 테스트의 여러 측면을 해결할 수 있습니다.

요구사항 관리 및 기능 안전

효과적이고 비용 효율적인 품질 및 테스트 전략은 명확하게 정의된 요구사항에 기반해야 합니다. 요구사항을 사용하면 제품의 정확한 기능을 정의하고 제품이 올바르고 완전히 테스트되는 것을 보장할 수 있습니다. 요구사항 관리 도구는 요구사항을 저장하고 분석하는 과정의 비용 효율성을 향상합니다.  게다가 규정 준수 표준은 상위 레벨과 하위 레벨의 요구사항과 제품의 요구사항 구현 사이 연결의 증명을 강조합니다.  대부분의 엔지니어링 프로젝트는 상위 레벨 스펙에서 시작하고, 프로젝트가 진행되면서 보다 자세한 스펙을 정의합니다. 스펙에는 제품의 각 엔지니어링 단계 통과를 안내하는 기술적, 절차적 요구사항이 포함되어 있습니다. 또한 하드웨어 회로도, 시뮬레이션 모델, 소프트웨어 소스 코드, 테스트 스펙 및 절차와 같은 작업 문서는 스펙에 정의된 요구사항을 준수하고 포괄해야 합니다.

그림 6.  NI Requirements Gateway는 기존 프로젝트 요구사항에서 실행된 테스트 및 테스트 결과까지 직접 추적성을 보여줄 수 있습니다.

요구사항에서 테스트, 측정 및 제어 소프트웨어까지의 관계를 추적하는 것은 구현을 검증하고, 변경된 요구사항의 전체 영향을 분석하고, 테스트 실패의 영향을 이해하는 데 매우 중요합니다. 이러한 커버리지 및 영향 분석을 수행하면 엔지니어가 요구사항을 충족하고 개발을 간소화할 수 있습니다.

공통의 검증 프레임워크를 사용하여 조기에 요구사항 고정

기능 안전 표준을 준수하여 프로젝트와 전자 시스템을 개발하려면 요구사항을 엄격하게 준수해야 합니다.  프로젝트 수명 주기 전반에 걸쳐 수행되는 모든 단계는 추적 가능해야 하며 시스템 수준의 요구사항에 직접 영향을 받아야 합니다.  프로젝트의 개발 단계에 상관없이, 테스트는 일정 부분 시스템 전체의 작동을 검증하도록 수행됩니다.  이러한 확인은 여러 지점에서 수행되고 요구사항에 대한 추적 가능성을 보여야 하므로, 요구사항이 일관되고 시간에 따라 변경되지 않는 것이 매우 중요합니다.  모든 프로젝트와 마찬가지로, 이는 어려운 일일 수 있으며 시간이 지나면서 시스템의 요구사항이 변경되면, 새로운 요구사항에 설계하는 것뿐만 아니라 새로운 요구사항을 확인하는 데에도 매우 비용이 많이 들 수 있습니다.  그 결과 기업은 처음에 최대한 신뢰할 수 있는 요구사항을 수립하여, 추후 변경사항이 줄이고 테스트 비용을 크게 절감할 수 있는 방법을 찾고 있습니다.

ISO 26262와 같은 표준을 보면, 요구사항에는 장애의 심각성, 장애 노출 빈도, 장애를 방지하거나 수정할 수 있는 제어 가능성의 세 가지 주요 요소에 기반한 ASIL (자동차 안전 무결성 레벨)이 할당됩니다.  이러한 세 가지 요소에 대한 정보가 많을수록 ASIL 레벨 할당에 대한 신뢰도가 높아지며, 나중에 요구사항 변경될 확률이 떨어집니다.  예를 들어, ECU의 프로토타입이 조기에 개발된 경우, 특정 장애에 노출되는 빈도를 모니터링하고 기록하여 장애가 발생할 가능성을 이해함으로써 ASIL 정의에 필수적인 정보를 제공할 수 있습니다.

일반적으로 ECU와 같은 디바이스의 프로토타이핑은 요구사항 정의의 지원과 개발 주기 초기 단계에서의 요구사항 확인이라는 두 가지 목적을 달성할 수 있습니다.  중요한 것은 프로토타이핑의 요구사항 정의를 개발 초기 단계로 옮기는 것입니다.  나중에 신속한 제어 프로토타이핑과 같은 단계를 통해 요구사항을 검증할 때, 동일한 프레임워크를 사용하여 이전 프로토타이핑 단계에서의 특정 테스트 구성요소를 재사용하면 상당한 시간과 노력을 절약할 수 있습니다.  조기 프로토타이핑에 투자된 시간과 노력은 특정 구성요소를 나중에 재사용 가능하도록 하여, 조기 프로토타이핑이 프로젝트 비용에 미치는 영향을 최소화하고 프로세스의 후반부에 요구사항을 변경하는 것보다 훨씬 저렴하게 합니다.

그림 7.  다른 유형의 검증을 위해 동일한 테스트 아키텍처에서 조기 프로토타이핑을 수행하여 요구사항을 더 잘 정의하면 전체 개발 시간을 절약할 수 있습니다.

인증된 상용 기성 검증 도구 사용하기

한발 물러서서 개발 중인 프로젝트를 아무것이나 떠올려 봅시다.  일반적으로 임의의 작업을 검증하고 어떤 요구사항을 확인해야 하는 경우, 테스트가 정확한지를 먼저 보장해야 합니다.  이제 이는 기능 안전 표준을 적용하는 규제 산업에 특히 해당됩니다.  확인에 오류가 발생하면, 프로젝트가 생산 단계로 넘어가고 안전이 필수적인 상황이 발생하면 매우 심각한 결과를 초래할 수 있습니다.  동시에 자동차 및 항공우주와 같은 많은 산업에서 전자 부품의 복잡성이 증가하기 때문에, 테스트에 필요한 시간이 증가하고 있지만, 테스트에 할당되는 시간도 반드시 같이 증가하는 것은 아니라, 일부 검증의 자동화에 대한 바람과 필요성이 커집니다.  그러나 테스트 자동화에 어떤 종류의 도구를 사용하려는 경우, 이 도구가 예상대로 작동하는지는 어떻게 알 수 있습니까?  또한 자체 테스트 자동화 도구를 개발하는 비용은 매우 클 수 있으며, 특히 기능 안전을 고려하여 설계하려는 경우에는 더욱 그렇습니다.  이뿐만 아니라 전반적인 검증을 위해 매우 구체적이고 철저한 문서화도 필요합니다.  이 문서를 제대로 만들려면 시간이 매우 많이 소요될 수 있기 때문에, 도구를 사용한다면 도구로 적절한 자료를 생성해야 합니다.  그렇다면 수동 검증이 유일한 방법입니까?

기능 안전 테스트에 대해 특정한 방식으로 적합성을 인증받은 상용 기성 검증 도구를 사용하면 이러한 요구사항을 해결할 수 있으며 테스트 도구에 대한 신뢰성도 높일 수 있습니다.  실제로, NI 얼라이언스 파트너인 CertTech LLC는 테스트 자동화 소프트웨어 도구 NI TestStand를 위한 자격 키트를 생성함으로써 이를 달성했습니다.  NI TestStand는 자동화된 테스트 및 검증 시스템을 더욱 신속하게 개발, 실행, 배포할 수 있도록 설계된 테스트 관리 소프트웨어로, 설치 후 즉시 사용이 가능합니다.  CertTech는 규제 산업과 기능 안전 표준에 풍부한 경험을 갖추고 있기 때문에 DO-178C나 ISO 26262 등의 표준에서 명시한 적격 도구를 사용하기 위해서 무엇이 필요한지 파악하고 있습니다.  NI TestStand용 자격 키트는 가장 일반적으로 사용되는 기능에 대한 포괄적인 요구사항 및 테스트 커버리지, 제공된 요구사항을 확인하는 완전한 테스트 세트, 신속 확장 가능한 프레임워크를 제공하므로 필요에 따라 커버리지를 확장할 수 있습니다.  또한 도구에서 필요한 문서를 생성하여 규정 준수에 필요한 자료로 사용할 수 있습니다.  전체 목표가 검증 프로세스를 완전히 투명하게 하여 테스트를 재생성 가능하게 하고, 완료된 작업의 모든 세부사항을 명확하게 하는 것이기 때문에 문서가 필수적입니다.

ISO 26262 및 DO-178C와 같은 일부 최신 기능 안전 표준에서는 수동으로 검토되지 않을 검증 및 확인 작업에 ‘적격 도구’를 사용하도록 하므로 NI TestStand와 같은 적격 도구 사용이 더욱 중요합니다.  이러한 표준에서는 도구가 적절한 테스트를 수행하지 못할 경우의 전체적 영향을 분석하고 ISO 26262와 같은 표준에서 TCL (도구 신뢰도)이라고 부르는 것을 할당하도록 요구합니다.  TCL을 결정하는 데는 두 가지 주요 요소가 있습니다. 첫 번째는 도구 영향 (TI)이고 두 번째는 도구 에러 감지 (TD)입니다.  TI0 또는 TI1는 도구 영향의 두 등급입니다. TI0은 오작동된 소프트웨어 도구가 안전 요구사항을 위반할 가능성이 없다는 논리를 주장할 수 있을 때 선택됩니다. 그 외 모든 경우에는 TI1가 선택됩니다.  도구 에러 감지는 TD1에서 TD3로 분류됩니다. TD1은 신뢰도가 높은 경우, TD2는 중간, TD3은 신뢰도가 낮은 경우 선택됩니다.  테스트 도구의 TCL 레벨 차이는 사용자에게 가는 부담의 차이로 나타납니다.

 

 

도구 에러 감지

TD1

TD2

TD3

도구 영향

TI1

TCL1

TCL1

TCL1

TI2

TCL1

TCL2

TCL3

그림 8.  ISO 26262 표준의 도구 신뢰도는 도구의 에러 감지 기능과 전반적인 도구 영향을 평가하여 계산됩니다.

요약하면, 도구의 신뢰성에 대한 신뢰도가 높으면, 도구가 예상대로 작동하는지 확인하기 위해 할 작업이 적어집니다.  결과적으로 이는 누구나 기능 안전 프로젝트 검증에 NI TestStand와 같은 상용 기성 테스트 자동화 도구를 활용할 수 있으며, 요구사항 검증에 필요한 신뢰성도 얻을 수 있다는 뜻입니다.

검증을 전체 프로젝트 관리와 원활하게 통합하여 조직 영향을 단순화하기

새로운 프로세스를 도입할 때의 가장 큰 문제 중 하나는 전체 조직에 미치는 영향을 다루는 것으로 특히 기존에 도입된 프로세스가 이미 있는 경우가 더욱 그렇습니다.  기능 안전 표준을 준수하는 전자 시스템을 개발하려는 기업은 이에 대한 완벽한 예입니다.  ISO 26262와 같은 기능 안전 표준을 준수하는 새로운 프로세스를 도입한다는 것은, 조직 전체 수준의 결정이며 반드시 따라야 할 철학입니다.  일반적으로 새로운 개별 역할, 특정 프로젝트 관리 프로세스, 주요 구성요소에 대한 지식을 동기화하는 새로운 방법이 도입됩니다.  말할 것도 없이, 이러한 기업들은 이미 자동차 SPICE와 같은 자체 개발 프로세스를 가지고 있으며, 이제 이러한 프로세스 위에 프로세스를 추가하려고 합니다.  이 문서에서 계속 논의한 것처럼, 프로세스의 검증 구성요소는 매우 중요하며 이러한 모든 측면에서 고려되어야 합니다. 따라서 테스트를 다른 모든 요소에 통합하는 것이 필수적입니다. 

이러한 문제를 해결하는 데는 IBM Rational에서 제공하는 것과 같은 어플리케이션 수명 주기 관리 도구를 사용하면 큰 도움이 될 수 있습니다.  이러한 제품에 통합된 유틸리티는 백엔드 지식 동기화 및 저장과 함께 전체 프로젝트 관리 프런트엔드에도 도움이 될 수 있습니다.  NI는 IBM와 협력하여 이 제품의 검증 및 확인 기능을 강화하고 있습니다.  NI의 테스트 도구를 IBM Rational 제품과 통합함으로써 테스트 구성요소를 보다 쉽게 관리하고 전체 어플리케이션 수명 주기 관리에 통합하여 일관성, 효율성 및 재사용성이 제고됩니다.  또한 NI 제품의 테스트 결과가 IBM 도구에 원활하게 통합되어 일관된 문서가 생성되고 저장되는 동시에 프로세스가 자동화됩니다. 이러한 유형의 프로젝트 관리와 문서화, 테스트 결과 관리의 결합은 조직 내의 전체적인 협업을 크게 향상시키고 개발 과정 전반에 걸쳐 최대한의 지식 동기화를 보장할 수 있습니다. 

그림 9.  이전에는 일반적으로 테스트를 별도로 생각했지만, 테스트를 어플리케이션 수명 주기 관리의 기타 측면에 통합함으로써 전체 과정을 포괄하는 품질 관리 시스템을 쉽게 만들 수 있습니다.

결론

기능 안전 표준 도입은 기업에 많은 과제를 안겨줍니다. 완전한 문서화, 시스템 수준 요구사항의 수집과 검증, 조직 수준의 변화와 효율적인 프로세스 구현은 적절한 방법과 접근 방식을 통해 지원할 수 있습니다. 테스트 구성요소의 재사용성과 요구사항의 자동 추적성에는 특별한 주의가 필요합니다. 수명 주기 관리 도구는 요구사항 추적을 돕고, 프로토타이핑은 요구사항을 조기에 통합하고 견고하게 고정할 수 있도록 돕습니다. 자동 검증에 사용되는 도구는 자격 키트를 통해 조직이 안전 표준을 준수할 수 있도록 지원합니다.  NI는 파트너 기업과 협력하여 기업들이 이러한 과제를 해결할 수 있도록 검증 및 확인 플랫폼을 제공합니다.