임베디드 C 코드 안정성을 향상시키기 위해 어떤 도구 또는 표준을 사용할 수 있습니까?

나는 일반적으로 스위치 모드 컨버터를 위해 C로 PIC를 프로그래밍한다. 코드의 안정성을 향상시키는 데 사용할 수있는 MISRA C 와 같은 다양한 정적 분석 도구 및 표준에 대해 들었습니다 . 더 알고 싶습니다. 내 상황에 적합한 표준 또는 도구는 무엇입니까?

임베디드 코드 유효성 검사는 특히 PIC와 같은 제한된 리소스 부분을 처리 할 때 까다 롭습니다. 부품의 엄숙한 제약과 이러한 종류의 장치에서 수행되는 "실시간"프로그래밍으로 인해 테스트 사례에 고급 코딩이없는 경우가 많습니다.

내 지침 중 일부는 다음과 같습니다.

1. 스펙이없는 경우 스펙 작성 : 스펙 에 대해 코딩하지 않는 경우 코드의 대상, 유효한 입력, 예상되는 출력, 각 루틴에 걸리는 시간, 얻을 수있는 것과 얻을 수없는 것을 문서화하십시오. clobbered 등-작동 이론, 흐름도, 아무것도 아닌 것보다 낫습니다.

2. 코드에 주석을 달아 라 : 무언가 분명한 것이 다른 사람에게 명백하거나 정확하다는 것을 의미하지는 않습니다. 평이한 언어 설명은 검토 및 코드 유지 관리에 필요합니다.

3. 방어적인 코드 : 일반적인 입력을위한 코드 만 포함하지 마십시오. 누락 된 입력, 범위를 벗어난 입력, 수학적 오버플로 등을 처리합니다. 코드 디자인에 포함되는 코너가 많을수록 배포시 코드의 자유도가 줄어 듭니다.

4. 정적 분석 도구 사용 : PC-lint와 같은 도구가 코드에서 찾을 수있는 버그의 수를 계산할 수 있습니다. 심각한 정적 테스트를위한 좋은 출발점으로 깨끗한 정적 분석 실행을 고려하십시오.

5. 동료 검토는 필수적입니다. 코드는 깨끗하고 잘 문서화되어 독립 당사자가 효율적으로 검토 할 수 있어야합니다. 문 앞에있는 자존심을 확인하고 비판이나 제안을 진지하게 고려하십시오.

6. 테스트는 필수적 입니다. 코드를 독립적으로 검증 할뿐만 아니라 자체 검증을 수행해야합니다. 다른 사람들은 상상할 수없는 방식으로 코드를 손상시킬 수 있습니다. 생각할 수있는 모든 유효한 조건과 모든 잘못된 조건을 테스트하십시오. PRNG를 사용하고 가비지 데이터를 공급하십시오. 가능한 모든 작업을 수행 한 다음 복구하고 다시 시도하십시오. 운이 좋으면 디버그 모드에서 코드를 실행하고 레지스터와 변수를 들여다 볼 수 있습니다. 그렇지 않은 경우 상태를 파악하려면 교묘하고 LED / 디지털 신호를 전환해야합니다. 장치. 필요한 피드백을 얻는 데 필요한 모든 것을하십시오.

7. 후드 봐 : 마 당신의 C 컴파일러에 의해 생성 된 머신 코드를 보면 두려워하지. 수백 번의 작업이 아니라면 아름다운 C 코드가 수십 번으로 터진 곳을 찾을 수 있습니다 (한 줄의 코드이므로 오른쪽?) 여러 인터럽트를 실행하는 데 시간이 오래 걸립니다 조건을 해고하고 무효화했습니다. 무언가가 비효율적으로되면 리팩토링하고 다시 시도하십시오.

PC에서 신뢰할 수있는 소프트웨어를 만드는 데 사용되는 대부분의 동일한 기술은 임베디드 개발에도 적용됩니다. 알고리즘을 하드웨어 특정 코드와 분리하고 단위 테스트, 시뮬레이션, 정적 분석 및 Valgrind와 같은 도구를 사용하여 별도로 테스트하는 것이 좋습니다. 그렇게하면 하드웨어에서만 테스트되는 코드가 훨씬 줄어 듭니다.

나는 C를 포기하지 않을 것이다. Ada와 같은 언어는 약간의 보증을 제공 할 수 있지만, 언어가 실제로하는 것보다 더 많은 것을 약속한다는 생각의 함정에 빠지기 쉽다.

MISRA-C는 일반적인 코드 품질을 개선하고 버그를 최소화하는 데 매우 유용합니다. 모든 규칙을 읽고 이해해야합니다. 대부분의 규칙은 좋지만 그 중 일부는 이해가되지 않습니다.

여기에 경고가 있습니다. MISRA 문서는 독자가 C 언어에 대한 광범위한 지식을 가진 사람이라고 가정합니다. 팀에 강화 된 C 베테랑이 없지만 정적 분석기를 가져오고 주어진 모든 경고를 맹목적으로 따르기로 결정하면 가독성이 떨어지고 우연히 버그가 발생할 수 있으므로 품질 코드 가 낮아질 가능성이 큽니다 . 나는 이것이 여러 번 일어나는 것을 보았고 코드를 MISRA 준수로 변환하는 것은 쉬운 일이 아닙니다.

적용 가능한 MISRA-C 문서에는 두 가지 버전이 있습니다. MISRA-C : 2004는 여전히 현재의 임베디드 산업 표준입니다. 또는 C99 표준을 지원하는 새로운 MISRA-C : 2012. 이전에 MISRA-C를 사용한 적이 없다면 후자를 구현하는 것이 좋습니다.

그러나 도구 공급 업체는 일반적으로 MISRA 검사를받을 때 MISRA-C : 2004를 참조합니다 (때로는 사용되지 않는 MISRA-C : 1998 버전을 참조하기도 함). 내가 아는 한 MISRA-C : 2012에 대한 도구 지원은 여전히 ​​제한적입니다. 지금까지 Klocwork, LDRA, PRQA 및 Polyspace와 같은 일부 정적 분석기 만 구현했다고 생각합니다. 더 많을 수도 있지만 지원하는 MISRA 버전을 확인해야합니다.

결정하기 전에 MISRA 문서를 읽고 시작하여 그 내용을 확인할 수 있습니다. misra.org 에서 £ 10에 구입할 수 있으며 ISO 표준 가격에 비해 상당히 저렴합니다.

Mathworks (MATLAB 사용자)에는 Polyspace 라는 정적 코드 분석 도구가 있습니다.

정적 코드 분석, 보푸라기 등과 같은 인터페이스 (정식 검토 프로세스 포함) 및 코드 범위 분석에 대한 신중한 정의 및 설계를 제안합니다.

또한 MISRA는 물론 UL1998 및 IEC 61508 표준을 포함하여 안전에 중요한 코드 설계에 대한 지침을 살펴볼 수도 있습니다.

이 질문에 대한 완전한 답을 얻으려면 코드가 디자인의 최종 표현이기 때문에 "코드 안정성"에 대한 생각을 억제하고 대신 "디자인 신뢰성"에 대해 생각합니다.

따라서 요구 사항부터 시작하여 요구 사항을 작성하고 검사하십시오. 요구 사항 문서가없는 경우 임의의 코드 줄을 가리키고 "왜 해당 줄이 필요한가?" "입력이 12-36VDC 사이 인 경우 전원 공급 장치가 5VDC를 출력해야합니다." 이것에 대해 생각하는 한 가지 방법은 해당 코드 줄을 요구 사항으로 추적 할 수 없다면 그것이 올바른 코드인지 또는 전혀 필요하다는 것을 어떻게 알 수 있습니까?

다음으로 디자인을 확인하십시오. 코드에 완전히 들어 있으면 괜찮습니다 (예 : 주석). 그렇기 때문에 코드가 실제로 의미하는 것을 수행하는지 알기가 어렵습니다. 예를 들어, 읽는 라인을 가질 수있는 코드 output = 3 * setpoint / (4 - (current * 5)); 가 current == 4/5충돌을 일으킬 수있는 유효한 입력은? 이 경우 0으로 나누기를 방지하려면 어떻게해야합니까? 작업을 완전히 피하거나 대신 출력을 저하 시킵니까? 이러한 경우를 처리하는 방법에 대한 설계 문서에 일반적인 참고 사항이 있으면 설계를보다 높은 수준에서 쉽게 검증 할 수 있습니다. 따라서 코드가 해당 디자인을 올바르게 구현하는지 확인해야하기 때문에 코드 검사가 더 쉬워졌습니다.

이와 함께, 코드 검사는 IDE가 '=='을 의미 할 때 '='와 같이 IDE에서 포착하지 못하는 일반적인 오류 (IDE를 사용하고 있습니까?)를 확인해야합니다. ', 진술해서는 안되는 세미콜론 등

이 글을 쓰면서 수년간의 소프트웨어 품질 교육 / 경험을 단일 게시물에 요약하는 것이 실제로 어렵다는 것이 나에게 일어납니다. 나는 의료 기기 용 코드를 작성하고 위는 우리가 접근하는 방법을 매우 단순화 한 요약입니다.