MISRA-C의 두번째 개정판 'MISRA-C:2004'

 

MISRA-C:2004 MISRA-C의 두번째 개정판(Guidelines for the use of the C language in critical systems)으로 자동차 뿐만 아니라 안전에 민감한 시스템(Critical System)에 사용될 수 있도록 만들어 졌습니다. MISRA-C:2004는 현재 높은 소프트웨어 신뢰성이 필요한 항공, 자동차, 우주, 원전 사업 등에 가장 널리 사용되고 있습니다. 141개의 룰이 있으며, 121개의 필수 룰과 20개의 권고 룰로 구성되어 있습니다. 각각의 룰들은 아래의 이미지에서 확인할 수 있듯이 "Environment" 부터 "Run-time failure"까지 21개의 그룹으로 구성되어 있습니다.

 

 

 

 

룰 가운데, 이번 포스트를 통해 EnvironmentLanguage Extensions에 대해 알아보겠습니다.

 

Environment

Rule1.1 All code shall conform to ISO 9899:1990 “Programming languages – C”, amended and corrected by ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996.

(필수)모든 코드는 ISO/IEC 9899:1990, Programming language – C (ISO/IEC 9899/COR 1:1995, ISO/IEC 9899/AMD 1:1995 ISO/IEC 9899/COR 2:1996에 의해서 추가 및 개정된 것)를 따라야 한다.

 

Rule1.2 No reliance shall be placed on undefined or unspecified behavior.

(필수) 미 정의 또는 미 규정 된 동작에 의존해서는 안 된다.

 

Rule1.3 Multiple compilers and/or languages shall only be used if there is a common defined interface standard for object code to which the languages/compilers/assemblers conform.

(필수) 여러 개의 언어나 컴파일러를 사용할 경우, object code에 대한 공통적인 인터페이스가 있어야 한다.

 

Rule1.4 The compiler/linker shall be checked to ensure that 31 character significance and case sensitivity are supported for external identifiers.

(필수) 컴파일러나 링커가 외부 식별자에 대하여 최대 31문자까지 지정이 가능하고, 대문자/소문자의 구분을 지원하고 있는지 검토되어야 한다.

 

Rule1.5 Floating-point implementations should comply with a defined floating-point standard.

(권장) 부동소수점의 사용은 정의된 부동소수점 규격에 따라야 한다.

 

 

Language extensions

 

Rule2.1 Assembly language shall be encapsulated and isolated.

(필수) 어셈블리 언어는 캡슐화되어 격리되어야 한다.

 

Rule2.2 Source code shall only use /* ... */ style comments.

(필수) 소스 코드에는  /*…*/ 스타일의 주석 표기법 만을 사용해야 한다.

 

Rule2.3 The character sequence /* shall not be used within a comment.

(필수) 주석의 시작은 /*에서 */로 끝나야 한다. 중간에 /*이 포함되어 있으면 안된다.

 

Rule2.4 Sections of code should not be “Commented out?”

(권장) 코드의 일부를 코멘트아웃 해서는 안된다. 필요 시 조건부 컴파일(#if…#endif)를 사용한다.

 

 

신고

DO-178C SOFTWARE PLANNING PROCESS Objective-5의 이해


* 시작에 앞서 용어는 Section4 의 게시물을 참고하면 된다.

 

1. Objective – 5 의 개요

생산될 소프트웨어에 대해 시스템 안전 달성요건(system safety objective)에 부합하는 소프트웨어 개발 표준을 정의한다.

 

2. Activity


4.2 Software Planning Process Activities


b. 프로젝트에 사용될 소프트웨어 개발 표준은 정의되거나 선택되어야 한다.

g. 소프트웨어 계획 프로세스가 완료 될 때까지, 소프트웨어 계획과 소프트웨어 개발 표준은 변경 통제 및 검토완료 되어야한다.

 

4.5 Software Development Standards

소프트웨어 개발 표준은 소프트웨어 개발 프로세스에 대한 규칙과 제약을 정의한다. 소프트웨어 개발 표준은 소프트웨어 요구사항 표준, 소프트웨어 설계 표준, 소프트웨어 코드 표준을 포함한다. 소프트웨어 검증 프로세스는 이러한 표준을 실제 산출물과 의도한 산출물 간의 적합성을 평가하기 위한 기준으로써 사용한다. 소프트웨어 표준 개발에 대한 활동은 아래를 포함한다.


a. 소프트웨어 개발 표준은 11장을 따라야 한다.

b. 소프트웨어 개발 표준은 주어진 소프트웨어 제품 또는 관련된 제품의 집합이 균등하게 설계되고 실행될 수 있도록 해야 한다.

c. 소프트웨어 개발 표준은 입증 될 수 없거나 안전관련 요구사항과 호환 가능하지 않은 산출물을 생산하는 방법 또는 구성물의 사용을 불가능하게 해야 한다.

d. 강건성은 소프트웨어 개발 표준에서 고려되어져야 한다.

 

3. Applicability by Software Level

해당 ObjectiveSW 레벨 A-C에서는 모두 수행해야 한다.

 

4. Outputs(산출물)

SW Requirements Standards

  소프트웨어 요구사항 표준 자세한 내용은 DO-178C11.6 항목 참조

• SW Design Standards

  소프트웨어 설계 표준 자세한 내용은 DO-178C11.7 항목 참조

• SW Code Standards

  소프트웨어 코드 표준 자세한 내용은 DO-178C11.8 항목 참조

     

    
5. Control Category by Software Level(SW
레벨에 따른 형상관리 수준)

SW 레벨 A, B에서의 산출물 SW Requirements Standards, SW Design Standards, SW Code StandardsCC1 수준으로 형상 관리한다.

SW 레벨 C에서는 산출물 SW Requirements Standards, SW Design Standards, SW Code StandardsCC2 수준으로 형상 관리한다.

 

6. 달성방법

시스템 안전성 목표에 일치하는 요구사항 표준, 설계 표준, 코드 표준을 정의함

요구사항 표준에는 구조적 방법, 식별체계, 표현방법(data flow diagram, UML), 요구사항 개발 및 관리 tool(DOORS), 제약사항. 파생 요구사항 제공 방법 등을 정의함

설계 표준에는 표현방법, 명명규칙, 제어조건, 설계도구 사용상의 제약사항, 복잡도 제한사항 등을 정의함

코드 표준은 Programming 언어, 소스코드 표현방식, 변수/함수 명명규칙, 조건사항, 코딩도구에 대한 제약사항 등을 정의함

 

다음에는 Objective – 6에 대해 알아보도록 하자.

신고

MISRA LDRA 적용


현재 신뢰성을 높이기 위해 다양한 코딩 룰이 존재합니다. 가장 잘 알려진 코딩 룰은 아마도 1998년에 처음 발표 된 MISRA(Motor Industry Software Reliability Association)일 것입니다. 최초 의도는 자동차 산업에서의 사용이었지만 현재 우주/항공, 의료장비, 국방, 철도 등 다양한 산업에서 광범위하게 적용되고 있습니다. MISRA Rule Mandatory, Required, Advisory로 구분되어 있습니다. 처음 발표 된 MISRA C ruleMISRA-C:1998이고, 2004년 이래로 새로운 표준인 MISRA-C:2004로 갱신되었으며, 현재는 MISRA C:2012까지 업데이트 되었습니다.



 

1. LDRA에서 MISRA 구분


 


 Default Strength 분류


  • (M) Mandatory         치명적인 결함을 일으킬 수 있는 필수적으로 지켜야하는 룰

  • (C) Checking             치명적인 결함을 일으키지는 않지만 지켜야하는 룰

  • (O) Optional             추가적으로 개발자의 재량으로 선택할 수 있는 룰

2. LDRA에 적용되어 있는 MISRA 룰 개수 및 구성


MISRA-C:1998

- 127 rules


119 implemented by LDRA


3 partially implemented by LDRA

5 not deemed to be statically analysable



MISRA-C:2004

- 141 rules


123 implemented by LDRA


4 partially implemented by LDRA


14 not deemed to be statically analysable


MISRA-C:2012

- Enhanced Guidelines


               ​119 implemented by LDRA

               。3 partially implemented by LDRA

               。5 not deemed to be statically analysable


- C90 / C99 support

- ​Directives / Rules

- Undecidable / Decidable rules

3. LDRA에서 MISRA 선택 방법

 


 

 

신고

Code Warrior & on Target 시험 사례

무인기체계 SWTarget 환경 구축에 따른 지원 결과 중, Code Warrior를 이용한 구축 사례에 대해 살펴 보겠습니다.


시험환경

IDE: Code Warrior 10.5 

Compiler: CodeWarrior

Target Chip : Freescale MPC 5674F 


환경구축 소요기간

60일 소요 (소요시간 단축 가능)

          계획수립: 2

          환경조사: 10

           환경개발연구: 20

          TLP 구축: 28


 


 

 

 

신뢰성 시험 흐름 구성도

 



 

 

시험과정 및 결과

Plugin 기능으로 CCS 에서 LDRA 실행

 

  

iSystem winIDEA Debugger와 연동되어 Test Case가 실제 Target 에서 수행

Debug -> Files for Download

파일 생성

LDRA TBrun에서 Create New Test Case 실행

 

 

 

 

Target에서 수행된 결과를 Host로 가져와 Coverage 달성

 


 

신고

DO-178C SOFTWARE PLANNING PROCESS

Objective - 4의 이해


 

* 시작에 앞서 용어는 Section4의 게시물을 참고 바랍니다.

 

1. Objective - 4의 개요

필요하다면 기존의 SW의 재활용, Tool 검증, 다양한 방법 등 추가적인 사항을 고려한다.


 

2. Activity

4.2 Software Planning Process Activities

f. 여러 버전의 상이한 SW(Multi-version dissimilar software)가 시스템에서 사용될 때,

SW 계획 과정에서 시스템 안전 목표(safety objectives)를 만족하는데 필요한 상이점(Dissimilarity)을 달성하기 위한 방법 및 도구를 선택해야 한다.

 

h. 비 활성화 코드(deactivated code)를 계획한다면, SW 계획 과정에서는 비 활성화 메커니즘(deactivation mechanism) 및 비 활성화 코드가 시스템 안전목표를 만족시키기 위해 어떻게 정의되고 검증(verify)되어야 하는지 서술해야 한다.

 

i. 사용자 수정 가능 SW(User-modifiable software)를 계획한다면, 그러한 설계를 입증하기 위해 관련된 프로세스, 도구, 환경, 그리고 데이터 아이템들(data items)(5.2.3 참고)이 소프트웨어 계획 및 표준에 명시되어야 한다.

 

j. 매개변수 데이터 항목(parameter data items)을 계획할 경우에는, 아래와 같은 항목을 고려해야 한다..

 

    1. 매개변수 데이터 항목을 사용하는 방법.

    2. 매개변수 데이터 항목의 SW 레벨.

    3. 매개변수 데이터 항목을 변경, 검증, 개발하기 위한 절차와 관련된 툴 인증

    4. SW 탑재 제어(load control) 및 호환성.

 

k. SW 계획 단계에서는 적용 가능한 추가적인 고려사항(additional considerations)을 다루어야 한다.

 


3. Applicability by Software Level

해당 ObjectiveSW 레벨 A~D 에서는 모두 수행해야 한다.

 

4. Outputs(산출물)

  • PSAC (Plan for Software Aspects of Certification)

         소프트웨어 인증계획 문서 자세한 내용은 DO-178C11.1항목 참조

  • SDP (Software Development Plan)

         소프트웨어 개발 계획 문서 자세한 내용은 DO-178C11.2항목 참조

  • SVP (Software Verification Plan)  

         소프트웨어 검증 계획 문서 자세한 내용은 DO-178C11.3항목 참조

  • SCM Plan (Software Configuration Management Plan)

         소프트웨어 형상 관리 계획 문서 자세한 내용은 DO-178C11.4항목 참조

  • SQA Plan (Software Quality Assurance Plan)

         소프트웨어 품질 보증 계획 문서 자세한 내용은 DO-178C11.5항목 참조

 

5, Control Category by Software Level (SW 레벨에 따른 형상관리 수준)

SW 레벨 A, B에서의 산출물 PSAC, SDP, SVP, SCM Plan, SQA Plan CC1 수준으로 형상 관리한다.

SW 레벨 C, D에서는 산출물 PSAC CC1수준으로, 산출물SDP, SVP, SCM Plan, SQA Plan CC2수준으로 형상 관리한다.

 

6. 달성방법

  • 기존에 개발되어 있는 SW를 재활용하는 경우에는 SW Safety Level 재평가, 개발환경 재정의, 형상관리 등을 추가로 고려함

  • Tool Qualification이 필요한 Tool에 대하여는 objective - 3을 참조함

  • Formal Method, Exhaustive Input Testing, 동일기능 이종 SW등과 같이 추가로 사용될 방법이나 기법에 대하여도 PSAC에 정의하여야 하며, 또한 SW 개발 결과물에 미치는 영향분석 및 선정 사유를 명시함

  • 이러한 도구나 방법에 대하여도 적절한 검증을 수행함

 

다음 포스팅에서는 Objective - 5에 대해 알아보도록 하자.

신고

DO-178C SOFTWARE PLANNING PROCESS

Objective - 3의 이해


  

1. Objective - 3의 개요

SW 라이프 사이클 프로세스의 활동을 위해 사용되는 방법. 도구 등을 포함하는 SW 라이프 사이클 환경이 선정되고 정의되어야 한다. (DO-178C 4.4참조)

 


2. Activity 

  • SW 개발환경

SW개발 환경은 높은 품질의 SW를 개발하는데 있어 중요한 요소이다. SW개발 시 몇 가지 환경들은 악영향을 끼칠 수 있다. 예를 들어 컴파일러(compiler)는 오류 있는 데이터를 만들어 에러를 일으킬 수 있고, 링커(linker)는 메모리할당 에러가 있는 것을 나타내지 못할 수도 있다. SW 개발 환경 방법 및 도구의 선택을 위한 활동은 아래와 같다.


  1. SW 계획 단계에서, SW 개발 환경은 소프트웨어 개발 시 잠재적인 위험을 줄일 수 있도록 선택해야 한다.

  2. 도구의 사용 또는 도구와 일부 SW 개발환경과의 결합은 어떤 한 부분에서 유입된 에러를 다른 부분에서 발견할 수 있을 정도의 확신 수준이 달성될 수 있도록 선택되어야 한다. 두 부분이 지속적으로 함께 사용되는 경우에 수용가능한 환경이 만들어 진다. 이러한 선택은 tool qualification필요성 여부에 대한 평가도 포함한다.

  3. SW 검증 절차 활동 또는 SW 개발 표준은 SW 등급을 고려하여 잠재적인 SW 개발 환경과 관련된 에러를 줄이기 위해 정의해야 한다.

  4. 도구의 사용을 위해 도구에 대한 certification이 필요하다면 도구의 사용절차가 계획에 적절하게 명시되어야 한다.

  5. 특정 프로젝트에서 SW 도구의 부가적인 옵션이 선택된다면, 옵션의 영향성은 계획단계에서 검토 및 명시되어야 한다. 이것은 특히 컴파일러와 자동코드 생성기에 중요한 사항이다.

  6. 도구의 알려진 문제점 및 한계점은 반드시 평가해야 하며 항공 SW에 부정적인 영향을 끼칠 수 있는 이런 이슈들은 반드시 다뤄져야 한다.

 

  • 언어 및 컴파일러 고려사항

    SW 제품의 검증이 성공적으로 완료된다면 컴파일러는 해당 제품에 적합하다고 여겨진다. 이 활동이 유효 하려면, SW 검증 절차는 프로그래밍 언어 및 컴파일러의 특별한 특성을 고려할 필요가 있다 SW 계획 과정은 검증을 위한 프로그래밍 언어 및 계획을 선택할 때 위와 같은 특성을 고려해야 한다. 활동은 아래와 같다.

    1. 어떤 컴파일러는 오브젝트코드의 성능을 최적화하려는 특성이 있다. 만약 SW 레벨에 적절하게 테스트케이스가 작성되었다면 최적화의 정확성은 검증될 필요가 없다. 그렇지 않다면, 구조적 커버리지(structural coverage) 분석에 대한 이러한 특징의 영향이 결정되어야 한다. 추가적인 정보는 DO-178C 6.4.4.2에 기술되어 있다.

    2. 특정기능을 구현하기위해, 몇 개의 컴파일러는 소스코드로 직접 추적할 수 없는 오브젝트코드를 생성 한다. 예를 들어 초기화, 내장(built-in)된 에러 검출, 예외처리가 있으며 추가적인 정보는 DO-178C 6.4.4.2.b에 서술되어 있다. SW계획 절차에서 오브젝트코드의 검출 및 범위(coverage)를 검증하기 위한 수단을 제공해야 하며, 적합한 계획(appropriate plan)에서 수단을 정의해야 한다.

    3. 만약 새로운 컴파일러, linkage editor 또는 로더(loader) 버전이 도입되거나, SW 라이프 싸이클 동안 컴파일러 옵션이 변경될 경우, 기존에 테스트 및 커버리지 분석은 더 이상 유효하지 않을 수 있다. 검증 계획은 DO-178C 6장 및 12.1.3장과 일관되는 재검증 수단을 제공해야 한다.

 

  • SW 테스트환경

    SW 테스트 환경 계획은 통합 프로세스의 결과를 시험하기 위해 사용될 방법, 도구, 절차, HW를 정의한다. 테스팅은 target computer, target computer emulator, 또는 host computer simulator을 이용하여 수행된다.

    테스팅의 활동들은 다음과 같다.

  •  

  1. Emulator 또는 simulatorDO-178C 12.2장에 기술된 것처럼 툴 자격을 갖춰야 한다.

  2. Target computeremulator(또는 simulator)의 차이점 및 에러를 검출하고 기능을 검증하는 능력에 대한 target computeremulator(or simulator)차이점의 결과를 고려해야 한다. SW 검증 프로세스에 의해 에러가 검출되어야 하며 SW 검증 계획(SVP)에서 에러 검출방법이 명시되어야 한다.

 

3. Applicability by Software Level

해당 ObjectiveSW 레벨 A~C 에서는 모두 달성해야 하며 레벨 D SW는 해당되지 않는다.

 

 

4. Outputs(산출물)


  • PSAC (Plan for Software Aspects of Certification)

         소프트웨어 인증계획 문서 자세한 내용은 DO-178C11.1항목 참조

  • SDP (Software Development Plan)

         소프트웨어 개발 계획 문서 자세한 내용은 DO-178C11.2항목 참조

  • SVP (Software Verification Plan)  

         소프트웨어 검증 계획 문서 자세한 내용은 DO-178C11.3항목 참조

  • SCM Plan (Software Configuration Management Plan)

         소프트웨어 구성 관리 계획 문서 자세한 내용은 DO-178C11.4항목 참조

  • SQA Plan (Software Quality Assurance Plan)

         소프트웨어 품질 보증 계획 문서 자세한 내용은 DO-178C11.5항목 참조


 

5. Control Category by Software Level

SW 레벨 A, B의 산출물 PSAC, SDP, SVP, SCM Plan, SQA Plan CC1을 기준으로 형상 관리하며, SW 레벨 C, D의 산출물 PSAC CC1을 기준으로, 산출물SDP, SVP, SCM Plan, SQA Plan CC2기준으로 형상 관리한다.

 

6. 달성방안

  • SDP SW 개발 절차 및 활동에서 활용하는 방법, 도구(Tool), HW장비를 선정한다.

  • Development Tools, Coding Rule, Programming Language, Editor, Compiler

  • Verification Tools: LDRA Testbed/TBrun, Debugging Tool

  • Management Tools: MS-Project, PMS, ClearCase, CVS, Doors

  • Tool 중에서는 Tool Qualification을 받아야 하는 것을 명시한다. (Ref. DO-178C 12.2)

  • Tool을 선정할 때에는 SW의 잠재적인 위험 및 결함을 최소화할 수 있는지를 고려한다.

  • SW가 탑재될 HW장비 또는 그 장비를 대신할 Emulator 또는 Simulator를 선정한다.

 

다음에는 Objective - 4에 대해 알아보도록 하자.


신고

소프트웨어 신뢰성 시험 환경구축 사례(2) – CCS 5

소프트웨어 신뢰성 시험 환경 구축에 따른 지원 결과 중 CCS 5를 이용한 구축 사례 대해 살펴보겠습니다.


  1. 시험환경

  • IDE: TI CCS 5.5

  • Compiler: CCS

  • Target Chip: TI TMS320F28335

      2.  환경구축

      1) 소요기간

  • 50일 소요

                계획수립: 2

                환경조사: 8

                환경개발연구: 15

                TLP 구축: 25일  (*현재 환경개발연구와 TLP 구축에서 시간단축이 가능하여 총 소요시간 2~3주 예상)

                           

           

       2) TLP 환경


      

 

 


       3) 신뢰성 시험 흐름 구성도 

 

     

 

 

    

      3.  시험과정 및 결과

      

      1) Plugin 기능으로 CCS 에서 LDRA 실행 

 

          

      

 

 

      2) 기능 검증을 위한 Test Case 생성

 

  • 동적시험을 위해 LDRA TBrun에서 함수를 우클릭하여 Create New Test Case를 선택

  • 오른쪽 밑의 Input / Output View 화면에서 Input / Output 값 지정

  • Run Driver 실행 후 Pass 결과 확인

​  

    ​   

 

 

신고

감항인증을 위한 DO-178C

항공용 SW개발 프로세스 컨설팅


감항인증을 위한 항공용 SW 안전성 국제 규격인 DO-178C Level A 기준에 따른

SW 개발 프로세스 구축 및 인증획득 지원 컨설팅을 수행합니다.




1. GAP 분석 및 개선사항 도출                                     


▶ GAP 분석 및 개선 전략 수립

- DO-178C 표준 프로세스 대비 고객의 현행 프로세스와의 GAP 분석

- 효과적인 GAP 감소를 위한 개선 전략 및 일정 수립에 대한 보고서 제공




2. 개선전략 수립 및 활동                                              


▶ 개발 프로세스 구축 및 활동 수행방안 제시

- GAP 분석 결과를 토대로 DO-178C에 따른 프로세스 구축

- 71개의 Objectives 달성을 위한 단계별 검증 활동 수행방안 제시

- 자동화 도구를 이용한 단계별 요구사항 추적성 확보방안


▶개발 단계별 시험환경 구축 및 시험방안 제시

- 구현 및 통합 시험단계를 위한 arget 시험환경 구축

- 시험 자동화 도구(LDRA)를 이용한 정적분석 및 동적시험 방안 제시


▶산출물 제공

- Level A의 71개 Objectives를 달성하기 위한 검토 체크리스트 제공

- 20여종의 전체 개발 단계 산출물 템플릿 제공




3. 프로세스 및 엔지니어링 교육                                    


▶ 감항인증을 위한 DO-178C 프로세스 교육

▶ 임베디드 프로그래밍 최적화 및 SW 테스트를 위한 엔지니어링 교육

▶ 고객 방문교육 및 사내 정기교육




4. 인증획득 지원                                                          


▶ DO-178C 기준의 인증심사 활동 지원

- FAA 인증심사원(DER) 보유

- FAA SOI)Stage Of Involvement)

  #1 ~ #4 체크리스트 기준으로 모의수행 지원

  (Planning, Development, Verification, Certification 단계 리뷰)


▶ 장비품의 기술표준폼 표준서(TSO) 지원

- TSO-C9 :  자동 조종 장치

- TSO-C129a : GPS를 이용한 탑재식 추가 항행 장치

- TSO-C112, TSO-C10b, TSC-C30c 등의 기술표준서 지원


▶DO-178C Tool Qualification Suppot Pack 지원

- SW 측면의 인증 계획서 (PSAC)

- Tool Qualification 계획서 (TQP)

- Tool 수행 완료 요약서 (TAS)



===========================================================================


컨설팅 담당 장정훈 차장 02.6945.2120

기술지원 문의 강유선 선임 02.6945.2141




신고

 

 

군용 항공기 감항인증 (Airworthiness) 종합 솔루션


군용 항공기 부품.구성품의 감항인증에 요구되는 SW QUALIFICATION을 위한 종합 솔루션을 제공합니다.



√ 군용 항공기 감항인증 프로세스


  * 법률 제12903, 군용항공기 비행안전성 인증에 관한 법률


 

 

구성품의 검증방법(MOC) : SW Qualification, TSO 등의 기준자료 적용


기종별 감항인증기준(TACC) : 방위사업청 [군용항공기 표준 감항인증 기준 고시]를 적용 작성


감항인증 지원 솔루션


1. SW 인증을 위한 기준자료(데이터) 개발 컨설팅


v방위사업청 [표준 감항인증 기준 ] 기반 TCSD 개발 지원

- 소프트웨어 요구사항명세서(SRS), 소프트웨어개발계획(SDP) 33

  * TCSD(Typical Certification Source Data)


vDO-178C 기반 SLCD 개발 지원 (SW 안전등급 SIL 적용)


- PSAC, SDP, SVP, SCMP, SQAP 22

  * SLCD(Software Life Cycle Data)



2. SW Verification(TEST)


v요구사항 기반 테스팅(Requirement Based Testing) & Test Coverage 입증

vDO-178C 기반 SW 안전등급(SIL)별 구조적 분석(Structural Coverage Analysis)


 

  

 

 

3. SW Certification 전문 교육




 

   


 

 

 

4. SW 인증 대행


vFAA Certificate / Approval 인증 대행

*미 FAA DER의 인증 발급 대행




 


=======================================================================================================================


컨설팅 담당 장정훈 차장 02.6945.2120

기술지원 문의 강유선 선임 02.6945.2141

 

신고

DO-178C SOFTWARE PLANNING PROCESS Objective-2의 이해



시작에 앞서 용어는 Section4의 게시물을 참조한다.

 

1. Objective-2의 개요

소프트웨어의 생명주기는 피드백 메커니즘, 완료 기준을 포함하는 프로세스로 결정된다.

자세한사항은 DO-178C 4.1b항목을 참조한다.

 


2. Activity 

  1. 4.2i: 사용자 수정 가능 소프트웨어(User-modifiable software)가 계획되어 있는 경우, 설계와 관련된 관련 프로세스, 도구, 환경 및 데이터 항목은 소프트웨어 계획 및 기준에 명시해야 한다. 

  1. 4.3b: 아래와 같은 소프트웨어의 계획을 정함으로써, 소프트웨어 생명주기 프로세스의 완료 기준 (transition criteria)조건을 만족할 수 있다.

  1. 다른 프로세스로부터의 피드백을 포함하여 프로세스에 입력한다.

  2. 입력에 따른 행동을 할 수 있는 통합 프로세스 활동을 한다.

  3. 도구, 방법, 계획 및 절차의 유효성이 있어야 한다.

 

3. Applicability by Software Level

해당 Objective는 소프트웨어 레벨 A~C 에서는 모두 달성해야 한다.


 

4. Outputs(산출물)

 

PSAC (Plan for Software Aspects of Certification)

         소프트웨어 인증계획 문서 자세한 내용은 DO-178C11.1항목 참조

  • SDP (Software Development Plan)

         소프트웨어 개발 계획 문서 자세한 내용은 DO-178C11.2항목 참조

  • SVP (Software Verification Plan)  

         소프트웨어 검증 계획 문서 자세한 내용은 DO-178C11.3항목 참조

  • SCM Plan (Software Configuration Management Plan)

         소프트웨어 구성 관리 계획 문서 자세한 내용은 DO-178C11.4항목 참조

  • SQA Plan (Software Quality Assurance Plan)

         소프트웨어 품질 보증 계획 문서 자세한 내용은 DO-178C11.5항목 참조

 


5, Control Category by Software Level

 

소프트웨어 레벨 A, B의 산출물 PSAC, SDP, SVP, SCM Plan, SQA Plan CC1을 기준으로 형상 관리하며, 소프트웨어 레벨 C의 산출물 PSAC CC1을 기준으로, 산출물SDP, SVP, SCM Plan, SQA Plan CC2기준으로 형상 관리한다.

 

 

다음에는 Objective-3에 대해 알아보겠다.

 

신고

+ Recent posts