자동차소프트웨어개발
자동차소프트웨어개발
추세
2020년 전장부품 비용 비중 50%
SDV(Software Defined Vehicle)로의 전환
조향장치의 각도 하나하나가 늦게 변환되거나, 제동이 늦게 걸리면 운전자의 안전과 직결
현재 자동차 SW코드 추산 2~3억라인
품질
ISO 9001 : 제품과 서비스의 품질을 관리하기 위한 표준
명시적, 묵시적 요구를 만족시키는 제품 또는 서비스의 능력에 관한 특성
명시적 : 수치적 등 고객이나 업체가 제시한 문서화된 구체적인 요구사항
묵시적 : 당연히 지켜야 할 것들
| 프로세스 품질(Process Quality) | 제품 품질(Product Quality) |
|---|---|
| 프로세스 정의(계획) | 개별 단계 산출물이 이전 산출물 기반인지 |
| 정의된 프로세스 수행 통제 | 개별단계 산출물이 이전과 일관성 유지하는지 |
| 지속적 개선 | 최종 결과물이 요구사항 만족하는지 |
-> PDCA
Plan, Do, Check, Act
프로세스 평가 : automotive spice
소프트웨어의 정의 프로그램 + 모든 산출물(요구사항, 테스트 결과, 분석 등의 문서)
질(Quality) + 비용(Cost) + 일정(Delivery) : QCD
각 요소간 Trade Off 존재
필요성
WBS : https://lion-insight.tistory.com/3
소프트웨어 개발 생명주기 : 소프트웨어를 어떻게 개발할 것인가에 대해 정의한 최상위 수준의 프로세스
주먹구구식 개발 모델(Build & Fix Model)
폭포수 모델(Waterfall Model) :
개발 전 과정을 체계적이고 순차적으로 접근
원형 모델(Prototyping Model) :
프로토타입을 만들고 단계별로 만들어나감
나선형 모델(Spiral Model) :
폭포수 및 원형 모델의 장점 수용, 위험 분석 추가
애자일
스크럼
V-model
| 고객/사용자 요구사항 | 인수테스팅 | |||||||
| 요구사항 개발 (분석) | 시스템 테스팅 | |||||||
| 아키텍쳐 설계 | 통합 테스팅 | |||||||
| 상세 설계 | 단위 테스팅 | |||||||
| 구현(코딩) |
A-SPICE(Automotive spice)
프로세스의 품질을 높여 제품의 품질을 높이기 위해 사용!
A-SPICE란?
Automotive Software Process Improvement and Capability dEtermination
A-SPICE는 SPICE(ISO/IEC 15504)를 기반으로 자동차 소프트웨어 및 시스템 개발에 특화
국제 표준은 아님, 독일자동차협회(vDA)에서 만든 표준 : 사실상 표준(De facto standard)
[https://vda-qmc.de/automotive-spice/]
전반적 SW 품질
자동차 분야의 특성을 반영한 프로세스 품질 평가 기준
OEM
기존 ISO/IEC 12207(Software Life Cycple Processes), ISO/IEC 330xx(Process Assessment) 에서 시작
현재 버전
A-SPICE 4.0 (2023)
A-SPICE 3.1 (2017) 아직 더 많이 사용
A-SPICE 구성 요소
1. 평가 대상
프로세스 참조 모델(Process Reference Model : PRM)
2. 평가 지표
프로세스 평가 모델(Process Assessment Model : PAM)
3. 평가 방법
측정 프레임워크(Measurement framework)
ISO/IEC 33020 를 채택
-> VDA-QMC에서 발표한 PDF에도 Process Reference Model과 Process Assessment Model만 기재됨
프로세스 참조 모델(Process Reference Model : PRM)
평가 대상 프로세스의 범위와 프로세스 별 졍의
프로세스의 ID(식별자), name(이름), purpose(목적), outcomes(성과)를 설명한 모델
프로세스를 32개의 형태로 나눠놓음
(출처 : https://vda-qmc.de/wp-content/uploads/2023/02/Automotive_SPICE_PAM_31_KR.pdf) 
조금 더 중요한 필수 프로세스 : VDA Scope
프로세스 평가 모델(Process Assessment Model : PAM)
프로세스 성과(Outcomes)*와 프로세스 속성(PA, Process Attribute)이 대상 프로젝트에 존재하는지 식별하고 만족하는지 평가하기 위한 지표를 정의한 모델
프로세스 평가 모델 = 프로세스 수행 지표 + 프로세스 능력 지표
프로세스 수행 지표 : 프로세스 성과의 수행 정도
프로세스 능력 지표 : 프로세슷 속성 성과의 달성 정도
프로세스 수행 지표(Process Performance Indicators) = 기본 프랙티스(Base Practices) + 작업 산출물(Work Products)
프로젝트 능력 지표(Process Capability Indicators) = 일반 프랙티스(Generic Practices) + 일반 자원(Generic Resources)
기본 프랙티스 : 활동 중심 평가 지표
작업 산출물 : 결과 중심 평가 지표
일반 프랙티스 : 활동 중심 평가지표
일반 자원 : 인프라 중심 평가 지표
프로세스의 능력 수준(CL : Capability Level)
0 ~ 5 능력 수준으로 구분
| 능력수준 0 | 능력수준 1 | 능력수준 2 | 능력수준 3 | 능력수준 4 | 능력수준 5 |
|---|---|---|---|---|---|
| 불완전한 프로세스 (Incomplete) | 수행된 프로세스 (Performed) | 관리된 프로세스 (Managed) | 정립된 프로세스 (Established) | 예측 가능한 프로세스 (Predictable) | 혁신 프로세스 (Innovating) |
OEM의 목표 : 능력 수준 2 (CL2)
| 능력수준 | 프로세스 속성 | 프로세스 능력 지표 | ||
| CL5 | 혁신 프로세스 | PA5.1 프로세스 혁신 | ||
| CL4 | 예측 가능한 프로세스 | |||
| CL3 | 정립된 프로세스 | |||
| CL2 | 관리된 프로세스 | |||
| CL1 | 수행된 프로세스 | |||
| CL0 | 불완전한 프로세스 |
프로세스 수행 지표 구성 요소
프로세스 식별자/이름 -> 프로세스 목적 -> 프로세스 성과 -> 기본 프랙티스, 작업 산출물
프로세스 능력 지표
능력 수준 -> 프로세스 속성 -> 프로세스 속성 성과 -> 일반 프랙티스, 일반 자원
측정 프레임 워크 : ISO/iEC 33020
| 등급 척도 | 기준 | |
|---|---|---|
| N | 0% ~ 15% | 프로세스 속성 달성 증거 없 |
| P | 15% ~ 50% | 일부 증거와 달성 성과 존재 |
| L | 50% ~ 85% | 체계적 대응한 뚜렷한 달성 성과(일부 약점 존재) |
| F | 85% ~ 100% | 완전하고 체계적 달성 성과 존재(심각한 약점 없음) |
A-SPICE 핵심 컨셉
1. Plug-in
필요에 따라 추가/제외가 가능
2. V 모델
검증(Verification) 과 확인(Validation)
개발 단계와 대응되는 테스트 단계를 나란히 배치해 “V”형태
Verification : 개발자 관점 테스트
Validation : 고객(사용자) 관점 테스트
3. “엘리먼트”, “컴포넌트”, “유닛”, “아이템”
| | | | ——– | ———————————————– | | 엘리멘트 | V 모델 왼쪽의 개체 | | 컴포넌트 | SWE.2의 최하위 엘리먼트 | | 유닛 | 최하위 컴포넌트 | | 아이템 | V 모델 왼쪽의 엘리먼트에 대응되는 오른쪽의 요소 |
4. 추적성과 일관성
| | | | ——– | ——————————————————————– | | 추적성 | 작업 산출물 내 관련 요소들 간 연결되어 추적 가능한지 | | 일관성 | 작업 산출물 내 관련 요소들 간 내용과 의미가 일관되게 반영되어 있는지 |
상호 보완
추적성이 필요한 이유 :
- 커버리지 분석 및 파악
- 변경에 대한 영향도 분석
- 요구사항의 구현상태 관리
5. “합의한다”와 “요약하고 의사소통 한다”(“Agree” and “Summarize and Communicate”)
6. “평가한다” “검증 기준” “준수 보장”(“Evaluate”, “Verification Criteria” and “Ensuring Compliance”)
요구사항 작성시 검증 담당자가 해당 기준으로 검증 가능한 수준으로 작성해야함
7. “전략”과 “계획”의 관계(The Relation Between “strategy” and “Plan”)
ISO 26262
ISO 21448
ISO 26262의 강화
ISO 21434
사이버 보안
개발 프로세스 단계별 활동과 산출물
소프트웨어 요구 공학
소프트웨어 요구사항의 중요성
소프트웨어 제품을 전체적으로 파악, 전체 개발 단계의 기준 및 가이드라인으로 활용
소프트웨어 요구사항의 정의
소프트웨어를 개발하기 위한 요구사항을 추출, 분석, 명세, 검증하며, 개발된 요구사항의 변경 및 추적을 관리하는 공학적 접근 방법
요구사항 개발/관리 프로세스
- 요구사항 도출
- 요구사항 분석
- 요구사항 명세
- 요구사항 검증
1.요구사항 도출
A-SPICE의 software Requirements Analysis Process(SWE.1, Software Engineering)
시스템 요구사항을 소프트웨어 요구사항으로 전환
BP1 ~ BP8 (Base practices)
2. 요구사항 분석
구조적 분석
객체지향 분석
3. 요구사항 명세
소프트웨어 요구사항 명세서(SRS) 작성
시스템 요구사항 명세서(SYRS, SWRS) 작성
IEEE 830에서 SRS 구성 항목 표준화
EARS(Easy Approach to Requirements Syntax) 명세 기법
4. 요구사항 검증
이해당사자 기대사항이 의도한대로 요구사항이 추출 및 분석되어, 소프트웨어 요구사항 명세서가 작성되었는지를 검토/확인하는 활동
요구사항 검토 체크리스트
소프트웨어 설계
프로그램을 구현하기 전에 소프트웨어를 구성하는 요소와 구조를 정의해 구현의 가반을 만드는 활동
A-SPICE의 Software Architectural Design Process(SWE.2)
아키텍처 설계 수립, 어떤 소프트웨어 요구사항이 어떤 엘리먼트로 할당될 지 식별, 정의된 기준과 비교하여 아키텍처 설계를 평가
BP 1 ~ BP 9 (Base practices)
| BP | 내용 |
|---|---|
| BP 1 | 소프트웨어 아키텍처 설계를 개발한다. |
| BP 2 | 소프트웨어 요구사항을 할당한다. |
| BP 3 | 소프트웨어 앨리먼트의 인터페이스를 정의한다. |
| BP 4 | 동적 행태를 서술한다. |
| BP 5 | 자원 소모 목표를 정의한다. |
| BP 6 | 대안의 소프트웨어 아키텍처를 평가한다. |
| BP 7 | 양방향 추적성을 수립한다. |
| BP 8 | 일관성을 보장한다. |
| BP 9 | 합의된 소프트웨어 아키텍처 설계를 의사소통한다. |
아키텍처 설계
상위 수준에서 소프트웨어 구성 요소들 간의 관계로 구성된 전체적인 구조를 설계하는 활동
3-레벨 모니터링 정적 아키텍처
| 레벨 | 내용 |
|---|---|
| 레벨 1 | 센서 수준 모니터링 |
| 레벨 2 | ECU 수준 모니터링 |
| 레벨 3 | 시스템 수준 모니터링 |
Strong cohesion, Losse coupling 응집도는 높이고, 결합도는 낮추고
소프트웨어 상세 설계
아키텍처 설계에서 도출된 소프트웨어 구성 요소들의 내부 데이터와 알고리즘 로직 등을 설계하는 활동
ISO 26262의 상세 설계 및 구현 원칙
unit design and implementation
소프트웨어 구현 및 통합
개별 소프트웨어 단위를 실행 가능한 형태로 구현하고, 이를 문서화하는 활동
코딩 표준
MISRA-C
C언어 기반 프로그램의 신뢰성, 안전성, 호환성을 확보하기 위한 156개의 Rule
예시) 표
순환 복잡도(Cyclomatic Complexity)
자동차 도메인 기준 10 이하 : 통과
10 이상 30 이하 : 조건부 통과
30 이상 : 반드시 수정
지속적 통합(Continuous Integration, CI)
SW 통합 오류를 개발 초기부터 예방하는 것
애자일 :
프로세스를 짧게
요구사항 자주 변경
고객에게 빠르게 배포해 피드백, 개선
소프트웨어 검증 및 확인
제품이 올바르게 만들어지고 있는가?
Static(정적 분석)
산출물 문서 및 소스 코드를 실행시키지 않고, 수작업이나 자동화 도구를 이용하여 분석
Review(문서, 코드), Inspection
Static Analysis based on Tool
Dynamic
소스 코드를 실제로 실행시켜 테스트를 수행
소스 코드 검토 체크리스트
소프트웨어 테스팅
품질(Quality)
명시적, 묵시적 요구를 만족시키는 제품 또는 서비스의능력에 관한 특성
소프트웨어 품질 확보 방법 유형
- 프로세스 품질
- 제품 품질
소프트웨어 테스팅
정상 조건 및 비정상 조건 사이의 차이점을 발견하기 위해 분석 및 평가하는 프로세스
-> 결함을 발견하려는 의도를 가지고 프로그램을 실행하는 프로세스
-> 제 3자가 행해야 품질을 더 높일 수 있음
테스팅과 디버깅의 차이
| 구분 | 테스팅 | 디버깅 | | ——— | —————————————————- | ————————————————————– | | 목적 | 알려지지 않은 결함의 발견 | 이미 알고 있는 결함의 수정 | | 담당자 | - 시스템 내부 관련자
- 테스팅 팀 등 외부의 제 3자 | 시스템 내부 관련자 | | 주요 작업 | 결함 발견 | - 결함의 정확한 위치 파악
- 결함의 타입 식별
- 결함 수정 |
블랙박스 테스팅과 화이트박스 테스팅
| 블랙박스 테스팅 | 화이트박스 테스팅 | | ———————— | ————————- | | 로직 제외, 출력에만 초점 | 모든 독립적인 경로를 수행 | | 명세기반 테스팅 | 구조기반 테스팅 | | 예시:
|
소프트웨어 형상 관리
소프트웨어 형상
소프트웨어 산출물(요구사항 명세서, 소스 코드 등)의 구성
소프트웨어 형상 관리 형상 항목을 식별하고, 변경을 통제 및 처리 상태를 모니터링함으로써 요구사항에 부합하는지 화인하는 활동
-> 무결성(Integrity), 추적성(Traceability) 확보
A-SPICE의 Configuration Management
TODO
결론적으로 무결성 증가
소프트웨어 추적 관리
TODO
자동차 사이버 보안
Security : 외부 -> 내부 로의 위협(hazard) : (attack)
ISO 26262 : 내부 -> 외부 로의 위협(hazard) : (Human Error)
최종
A-SPICE(기준) + 안전(Safety, ISO 26262) + 사이버 보안(Security, ISO 21434)
참고 자료
https://developers.hyundaimotorgroup.com/blog/127
개발과 테스트 대응됨
밑에 깔려있는 여러 컨셉