임베디드 소프트웨어의 오류를 줄이기 위한 새로운 코딩 습관 개발

애플리케이션 크기와 복잡성은 지난 10년 동안 상당히 복잡해졌습니다. 자동차 부문을 예로 들어보겠습니다. 뉴욕 타임즈에 따르면 , 20년 전만 해도 일반 자동차에는 백만 줄의 코드가 있었지만 10년 후 제너럴 모터스 2010 Chevrolet Volt에는 F-35 전투기보다 많은 천만 줄의 코드가 있었습니다. 오늘날 평균적인 자동차에는 1억 라인 이상의 코드가 있습니다.

많은 메모리와 성능을 갖춘 32비트 이상의 프로세서로의 전환으로 기업은 훨씬 더 많은 부가가치 기능을 설계에 구축할 수 있게 되었습니다. 그것이 장점입니다. 단점은 코드의 양과 복잡성으로 인해 종종 애플리케이션 보안 및 안전에 영향을 미치는 오류가 발생한다는 것입니다.

더 나은 접근 방식이 필요한 시점입니다. 소프트웨어에서 두 가지 주요 유형의 오류를 찾을 수 있으며 오류 발생을 방지하는 도구를 사용하여 해결할 수 있습니다.

• 코딩 오류:배열의 경계 외부에 액세스를 시도하는 코드를 예로 들 수 있습니다. 이러한 종류의 문제는 정적 분석을 수행하여 감지할 수 있습니다.
• 애플리케이션 오류:애플리케이션이 수행해야 하는 작업을 정확히 알아야만 감지할 수 있습니다. 즉, 요구사항에 대한 테스트를 의미합니다.

이러한 오류를 해결하면 설계 엔지니어가 더 안전하고 안전한 코드를 향한 먼 길을 가게 될 것입니다.

코드 검사를 통한 예방

코드의 오류는 이메일 및 인스턴트 메시징의 오류만큼 쉽게 발생합니다. 이것은 엔지니어가 바쁘고 교정을 하지 않기 때문에 발생하는 단순한 오류입니다. 그러나 복잡성과 함께 엄청난 문제를 일으키는 설계 오류 영역이 발생합니다. 복잡성으로 인해 시스템 작동 방식, 데이터 전달 방식 및 값 정의 방식에 대한 완전히 새로운 수준의 이해가 필요합니다. 오류가 복잡성으로 인해 발생하든 일종의 인적 문제로 인해 발생하든 상관없이 코드 조각이 배열 범위 밖의 값에 액세스하려고 시도할 수 있습니다. 그리고 코딩 표준이 이를 포착합니다.

임베디드의 다음 관련 기사에도 관심이 있을 수 있습니다.

MISRA C/C++로 안전하고 안정적인 임베디드 시스템 구축

정적 분석을 사용하여 보안에 중요한 오픈 소스 서버 애플리케이션의 코딩 오류 감지

그러한 오류를 피하는 방법은 무엇입니까? 처음부터 거기에 두지 마십시오. 이것이 명백하고 거의 불가능하게 들리지만 이것이 바로 코딩 표준이 테이블에 가져다주는 가치입니다.

C 및 C++ 세계에서 소프트웨어 결함의 80%는 언어의 약 20%가 올바르지 않거나 부적절하게 사용되어 발생합니다. 코딩 표준은 문제가 있는 것으로 알려진 언어 부분에 대한 제한을 만듭니다. 결과:결함이 방지되고 소프트웨어 품질이 크게 향상됩니다. 몇 가지 예를 살펴보겠습니다.

대부분의 C 및 C++ 프로그래밍 오류는 각 언어에 고유한 정의되지 않은, 구현에서 정의된, 지정되지 않은 동작으로 인해 발생하며, 이는 소프트웨어 버그 및 보안 문제로 이어집니다. 이 구현 정의 동작은 부호 있는 정수가 오른쪽으로 이동될 때 상위 비트를 전파합니다. 컴파일러 엔지니어가 사용하는 것에 따라 결과는 0x40000000 또는 0xC0000000이 될 수 있습니다. C는 함수에 대한 인수가 평가되는 순서를 지정하지 않기 때문입니다.

그림 1. 일부 C 및 C++ 구성의 동작은 사용되는 컴파일러에 따라 다릅니다. 출처:LDRA

그림 2에서 - rollDice() 함수는 단순히 "1,2,3 및 4" 값을 보유하는 순환 버퍼에서 다음 값을 읽습니다. 예상되는 반환 값은 1234입니다. 그러나 이에 대한 보장은 없습니다. 하나 이상의 컴파일러에서 값 3412를 반환하는 코드를 생성합니다.

그림 2. 일부 C 및 C++ 구조의 동작은 언어에 의해 지정되지 않습니다. 출처:LDRA

C/C++ 언어에는 다른 많은 함정이 있습니다. goto와 같은 구문 사용 또는 malloc; 부호 있는 값과 부호 없는 값의 혼합 또는 "영리한" 코드는 매우 효율적이고 간결하지만 너무 비밀스럽고 복잡하여 다른 사람들이 이해하기 어렵습니다. 이러한 문제는 결함, 값 오버플로가 갑자기 음수가 되거나 코드를 유지 관리할 수 없게 만들 수 있습니다.

코딩 표준은 이러한 질병에 대한 예방 조치를 제공합니다. 그들은 이러한 문제가 있는 구성의 사용을 방지하고 개발자가 문서화되지 않은 지나치게 복잡한 코드를 생성하고 스타일의 일관성을 확인하는 것을 방지할 수 있습니다. 탭 문자를 사용하지 않거나 괄호가 특정 위치에 있는지 확인하는 등의 사항도 모니터링할 수 있습니다. 사소해 보이지만 스타일을 따르면 수동 코드 검토에 큰 도움이 되고 다른 편집기에서 코드를 볼 때 다른 탭 크기로 인해 발생하는 혼동을 방지합니다.

MISRA 구조

가장 잘 알려진 프로그래밍 표준은 자동차 산업을 위해 1998년에 처음 출판된 MISRA 지침이며 현재는 어느 정도의 MISRA 검사를 제공하는 많은 임베디드 컴파일러에서 일반적으로 채택하고 있습니다. MISRA는 C 및 C++ 언어 내에서 문제가 있는 구성 및 관행에 중점을 두어 일관성 있는 문체 특성의 사용을 권장하는 동시에 어떤 것도 제안하지 않을 것을 권장합니다.

MISRA 지침은 각 규칙이 존재하는 이유에 대한 유용한 설명과 함께 해당 규칙의 다양한 예외에 대한 세부 정보, 정의되지 않은, 지정되지 않은, 구현 정의 동작의 예를 제공합니다. 그림 3은 안내 수준을 보여줍니다.

그림 3. 이러한 MISRA C 참조는 정의되지 않은, 지정되지 않은 및 구현 정의 동작과 관련이 있습니다. 출처:LDRA

MISRA 지침의 대부분은 "결정 가능"이며, 이는 도구가 위반 여부를 식별할 수 있음을 의미합니다. 그러나 일부는 "결정 불가"이며, 이는 도구가 위반 여부를 추론하는 것이 항상 가능한 것은 아님을 의미합니다.

초기화해야 하는 시스템 함수에 전달된 초기화되지 않은 변수는 정적 분석 도구가 시스템 함수의 소스 코드에 액세스할 수 없는 경우 오류로 등록되지 않을 수 있습니다. 위음성 또는 위양성 가능성이 있습니다.

2016년에는 안전뿐만 아니라 보안에 중요한 코드에 대한 검사를 제공하기 위해 14개의 지침이 MISRA에 추가되었습니다. 그림 4는 새로운 지침 중 하나인 지침 4.14에서 이 문제를 해결하고 정의되지 않은 동작으로 인한 함정을 방지하는 방법을 보여줍니다.

그림 4. MISRA 지침 4.14는 정의되지 않은 동작으로 인한 함정을 방지하는 데 도움이 됩니다. 출처:LDRA

엄격한 코딩 표준은 전통적으로 자동차, 비행기, 의료 기기와 같은 중요한 애플리케이션을 위한 기능적으로 안전한 소프트웨어와 관련이 있었습니다. 그러나 코드의 복잡성, 보안의 중요성, 유지 관리 및 업그레이드가 용이한 강력한 고품질 코드 생성의 비즈니스 중요성으로 인해 코딩 표준은 모든 개발 작업에서 매우 중요합니다.

처음부터 코드에 오류가 발생하지 않도록 함으로써 개발 팀은 다음을 수행해야 합니다.

• 광범위한 디버깅의 필요성 감소
• 일정을 더 잘 관리하고
• 전체 비용을 줄여 ROI를 제어합니다.

코드 검사는 엄청난 잠재적 이점이 있는 도구 상자를 제공합니다.

테스트 도구로 1파운드의 치료

코드 검사가 많은 문제를 해결하는 동안 애플리케이션 버그는 제품이 해야 할 일을 하고 요구 사항이 있음을 의미하는지 테스트해야만 찾을 수 있습니다. 애플리케이션 버그를 피하려면 올바른 제품을 설계하고 제품을 올바르게 설계해야 합니다.

올바른 제품을 설계한다는 것은 요구사항을 미리 설정하고 요구사항과 소스 코드 간의 양방향 추적성을 보장하여 모든 요구사항이 구현되고 모든 소프트웨어 기능이 요구사항으로 역추적하는 것을 의미합니다. 요구 사항을 충족하지 않는 누락되거나 불필요한 기능은 애플리케이션 버그입니다. 제품권 설계는 개발된 시스템 코드가 프로젝트 요구사항을 충족하는지 확인하는 과정입니다. 요구 사항 기반 테스트를 수행하여 이를 달성합니다.

그림 5는 양방향 추적 가능성의 예를 보여줍니다. 선택된 단일 함수는 함수에서 하위 수준 요구 사항, 상위 수준 요구 사항, 마지막으로 시스템 수준 요구 사항으로 업스트림을 추적합니다.

그림 5. 단일 기능이 선택된 양방향 추적성의 예입니다. 출처:LDRA

그림 6은 상위 수준 요구 사항의 선택이 시스템 수준 요구 사항에 대한 업스트림 추적 가능성과 하위 수준 요구 사항 및 소스 코드 기능에 대한 다운스트림 추적 가능성을 모두 표시하는 방법을 보여줍니다.

그림 6. 이것은 요구 사항이 선택된 양방향 추적 가능성의 예입니다. 출처:LDRA

추적 가능성을 시각화하는 이러한 기능을 통해 수명 주기 초기에 애플리케이션 버그를 감지할 수 있습니다.

코드 기능을 테스트하려면 수행해야 하는 작업에 대한 인식이 필요하며, 이는 각 기능이 수행하는 작업을 명시하는 낮은 수준의 요구 사항이 있음을 의미합니다. 그림 7은 이 경우 단일 기능을 완전히 설명하는 하위 수준 요구 사항의 예를 보여줍니다.

그림 7. 이것은 단일 기능을 설명하는 하위 수준 요구 사항의 예입니다. 출처:LDRA

테스트 케이스는 그림 8과 같이 낮은 수준의 요구 사항에서 파생됩니다.

그림 8. 테스트 케이스는 낮은 수준의 요구 사항에서 파생됩니다. 출처:LDRA

그런 다음 단위 테스트 도구를 사용하여 이러한 테스트 사례를 호스트 또는 대상에서 실행하여 코드가 요구 사항에서 말하는 대로 동작하는지 확인할 수 있습니다. 그림 9는 모든 테스트 케이스가 회귀되어 통과되었음을 보여줍니다.

그림 9. 이것은 도구가 단위 테스트를 수행하는 방법입니다. 출처:LDRA

테스트 케이스가 실행되면 모든 코드가 실행되었는지 확인하기 위해 구조적 적용 범위를 측정해야 합니다. 커버리지가 100%가 아니라면 더 많은 테스트 케이스가 필요하거나 불필요한 코드를 제거해야 할 수 있습니다.

코딩의 새로운 습관

의심의 여지 없이 연결성, 더 빠른 메모리, 풍부한 하드웨어 플랫폼 및 특정 고객 요구로 인해 소프트웨어 복잡성과 오류가 급증했습니다. 최신 코딩 표준을 채택하고, 코드에 대한 메트릭을 측정하고, 요구 사항을 추적하고, 요구 사항 기반 테스트를 구현하면 개발 팀이 고품질 코드를 만들고 책임을 줄일 수 있는 기회를 얻을 수 있습니다.

규정 준수를 요구하는 표준이 없을 때 팀이 이러한 새로운 습관을 채택하는 정도는 그들이 가져오는 게임 변화에 대한 기업의 인식에 달려 있습니다. 제품이 안전에 중요한지 보안에 중요한지 여부에 관계없이 이러한 관행을 채택하면 코드의 유지 관리 가능성과 견고성에 밤낮으로 차이를 만들 수 있습니다. 클린 코드는 새로운 기능의 추가를 단순화하고 제품 유지 관리를 용이하게 하며 비용과 일정을 최소한으로 유지합니다. 이 모든 특징은 회사의 ROI를 향상시킵니다.

제품이 안전이 중요하든 그렇지 않든 이는 분명 개발팀에게만 이익이 될 수 있는 결과입니다.

>> 이 기사는 원래 다음 날짜에 게시되었습니다. 자매 사이트인 EDN.