본문 바로가기

ISO26262

좋은 요구사항의 기준을 바꾸자: 독자 중심의 요구공학 최근 회사에서 진단 요구사항과 진단 매뉴얼 개발 프로세스를 정립하는 작업을 진행하면서, 한 가지 잊고 있었던, 매우 당연한 사실을 다시 생각하게 되었습니다. 지금까지의 고민들은 요구사항을 얼마나 상세하게 작성했는지, 그리고 상세하게 작성하기 위해 무엇을/어떻게 해야 하느냐가 고민의 포인트였는데, 이번 계기를 통해 요구사항을 상세하게 쓰는 것 자체가 곧바로 품질을 의미하지는 않는다는 점을 다시 한번 느끼게 되었다는 것입니다. 초기에는 부족했던 진단 요구사항을 보완한다는 목표가 분명했고, 그래서 진단 조건을 더 상세히 적고, 신호 수준까지 상세한 설명을 덧붙이며, 진단 알고리즘과 임계값, 저장 데이터까지 가능한 많은 정보를 문서에 담을 수 있도록 노력했습니다. 그결과, 작성자 입장에서는 “이 정도면 충분하.. 더보기
자동차 기능안전 온톨로지 (3): 클래스간 관계 정의하기 (Object Property) 기술안전 요구에서 시스템 구조까지, 표준을 온톨로지로 다시 읽다 기능안전 관련 업무를 진행하다보면, 갑자기 드는 생각이 있습니다. 일종의 호기심일 수도 있겠지만, 요즘같이 AI가 보편화되어가고 있으며, SDV 시대가 도래하고 있는 과도기적 시점에서 볼 때 어찌보면 또 당연한 질문일 수도 있을거 같습니다. “ISO 26262가 담고 있는 이 복잡한 세계를, 기계도 이해할 수 있는 언어로 다시 쓸 수 있을까?” 자동차 기능안전 온톨로지를 만든다는 것은 단순히 표준 문서를 요약하는 일이 아닙니다. 앞선 포스팅에서 정의하였다시피, 이미 Item, Hazard, SafetyGoal, FSR, TSR, System, ECU, Function 같은 Named Class와 계층 구조를 설계했다면, 이는 일종의 “등장인.. 더보기
자동차 기능안전 온톨로지 (1): Named Class (Top-Level Class) 자동차 한 대는 수많은 전자제어장치(ECU), 센서, 액추에이터, 그리고 그 사이를 잇는 신호들로 이루어져 있습니다. 이 모든 요소들이 어떻게 연결되고, 어떤 기능을 수행하며, 또 어떤 안전 목표를 지향하는지를 하나의 지식 체계(Ontology) 안에 담을 수 있다면 어떨까요? 그 중심에는 바로 Named Class, 즉 “이름 붙은 개념”이 있습니다.1. 온톨로지의 첫 단추, Named Class란?온톨로지(Ontology)는 지식을 “컴퓨터가 이해할 수 있는 언어”로 표현하기 위한 방법론입니다. 그중에서도 Named Class는 온톨로지의 뼈대(Skeleton) 에 해당합니다. 쉽게 말해, “세상에 어떤 개념들이 존재하는가”를 정의하는 역할을 합니다.자동차 기능안전 온톨로지에서 Named Class는.. 더보기
SW Qualification - 안해도 당장은 굴러간다! 오늘 조금 특별한 만남이 있었습니다. 시간은 짧았지만, 흔치 않은 주제로 이야기를 나누다 보니 개인적으로 정말 재밌고 유쾌한 시간이었습니다. 그런데 대화가 진행될수록, 마음 한켠에 묘한 안타까움이 퍼졌습니다. 아마도 오늘의 주제가 Code Library Qualification이었기 때문일지도 모르겠습니다.국내에서는 이 주제에 대한 정리된 사례가 아직 드물고, 심지어 OEM도 필요성은 인식하면서도 실제 개발과 양산의 전면에 세우지 못하는 경우가 많다는 이야기가 나왔습니다. 특히 자동차 소프트웨어 분야에서 라이브러리의 잘못된 사용은 안전과 신뢰성과 맞닿아 있는데도, 현실의 우선순위 속에서는 자주 “나중에 하자” 또는 "업체가 해야 할 일이야"로 밀리는 장면이 겹쳐 보였습니다.사실 실제 개발 현장에서는 라이.. 더보기
자동차 소프트웨어 Configuration: SW 플랫폼을 위한 필수 전략 지난 포스팅에서 하드웨어 플랫폼 개념을 차용한 소프트웨어 플랫폼화에 대한 생각을 정리하며 여기에는 분명 본질적 한계가 있다는 점을 알아 보았습니다. 하드웨어는 공차, 수명, 물리적 규격을 기준으로 공통화를 설계하지만, 소프트웨어는 가변성(Variability), 비가시성(Invisibility)이 존재하는 조금은 특별한 세계입니다. 그래서 소프트웨어 플랫폼의 핵심은 "공통 부품"을 이용한 플랫폼화가 아니라, "가변성"을 이용한 "Configuration"이어야 합니다. 소프트웨어 공용화(플랫폼화)... 잘못된 길로 가는 우리...주변에서 소프트웨어 개발 효율성과 관련하여 이런 이야기를 많이 듣습니다. "제품 간 공통된 기능은 하나로 묶어서 공용화 하겠습니다."“재사용 가능한 공통 모듈을 정의하여, 하나.. 더보기
제어기 레벨 테스트 vs. 차량 레벨 테스트 자동차 소프트웨어 개발에서 단품(제어기) 레벨 테스트는 기본 중의 기본입니다. 실제 개발 현장에서 “테스트”라는 말은 익숙하지만, 그 속을 들여다보면 단계와 목적에 따라 전혀 다른 세계가 펼쳐집니다. 특히 단품(제어기) 레벨 테스트와 차량 레벨 통합 테스트는 모두 품질을 보장하기 위한 필수 절차이지만, 접근 방식과 검증 관점은 크게 다릅니다. 단품 테스트는 한 개의 제어기를 고립된 환경에서 다루며, 입력과 출력 신호가 규격에 맞는지, 비정상 상황에서도 예측 가능한 반응을 하는지를 세밀하게 확인합니다. 반면 차량 테스트는 수십 개 제어기와 센서, 액추에이터가 동시에 작동하는 복잡한 환경에서, 운전자가 체감하는 경험과 안전성을 중심으로 검증합니다. 이 차이는 단순한 시험 환경의 차이가 아니라, 관찰 포인트,.. 더보기
ASIL 재분배 및 안전성 확인을 위한 차량 레벨 기능안전 프레임워크 한국자동차공학회(KSAE) 2025년 춘계 학술대회에서 5월 21일 논문을 발표하였습니다.현대오토에버 연구원분들과 함께 진행하고 있는 연구 중, 일부 중간 과정을 정리한 내용이라 아직은 부족함이 많지만 조금씩 발전 시켜나갈 예정에 있습니다. 발표 자료 작성과 발표 하시느라 수고하신 현대오토에버 김현성책임과 함께한 모든분들께 이자리를 빌어 감사의 말씀 전합니다.1. 배경과 문제 정의: ECU 중심 분석의 한계ISO 26262에서는 전기전자 시스템에서의 기능안전(Functional Safety)을 확보하기 위해 HARA(Hazard Analysis and Risk Assessment)를 수행하고, 이에 따라 ASIL(Automotive Safety Integrity Level)을 할당합니다. 그러나 실제 산.. 더보기
ISO/PAS 8800: AI 기술, 아키텍처 및 개발 조치 선택 AI 기술 발전은 다양한 산업에서 혁신을 이끌고 있지만,특히 안전이 중요한 분야에서는 기술 선택과 개발 과정에서 세심한 고려가 필요합니다.이를 위해 ISO/PAS 8800에서는 AI 기술과 아키텍처를 선택하고 개발하는 과정에서안전 요구사항을 충족하기 위한 주요 전략과 방법을 소개하고 있습니다.이번 포스팅에서는 ISO/PAS 8800:2024에서 언급하고 있는 AI 기술,그리고 아키텍처 및 개발 조치 선택에 대한 내용을 살펴보도록 하겠습니다.  이번 포스팅은 ISO/PAS 8800:2024, 10. Selection of AI Technologies, Architectural and Development Measures를 기반으로 작성하였습니다.  1. AI 기술을 선택하는 순간: "우리의 선택이 안전을.. 더보기

티스토리툴바