내 머리속 지우개

SDV(SW Defined Vehicle) 발전 레벨과 제어적 안전의 변화

상용차(트럭 & 버스)는 대형 화물과 다수의 승객을 운송하는 중요한 이동 수단으로, 안전성이 최우선으로 고려되어야 합니다. 특히, 자동차 기술이 기계적 제어에서 전자제어를 거쳐 소프트웨어 중심으로 발전함에 따라, 상용차에서도 안전 시스템이 크게 변화하고 있습니다. 이번 포스팅에서는 소프트웨어 정의 차량(SDV, Software Defined Vehicle) 발전 단계를 분석하고, 제어적 안전이 어떻게 향상되는지 살펴보겠습니다. 관련 글 더 보기SDV 시대에 피할 수 없는 기술적 부채와의 동행SDV를 위한 자동차 부품 공급망 변화가 필요하다.Ethernet 기반 차량 네트워크 설계에서 Functional Safety 고려사항 상용차(Commercial Vehicle) 중심의 SDV 전환 전략 수립 시 고려..

소프트웨어 개발에서 성공적인 시스템을 구축하기 위해서는 사용자의 기대(니즈, Needs)를 정확하게 이해하고, 이를 충족할 수 있도록 구체적인 조건(요구사항, Requirements)으로 변환하는 과정이 필수적입니다. 그러나 많은 프로젝트에서 이 과정이 제대로 수행되지 않으면, 최종적으로 사용자의 기대와 다르게 동작하는 소프트웨어가 개발되는 경우가 많습니다. 소프트웨어 니즈와 소프트웨어 요구사항은 밀접한 관계를 가지지만, 개념적으로 명확한 차이를 갖고 있습니다. 소프트웨어 니즈는 사용자가 원하는 바를 반영하는 상위 수준의 개념이며, 소프트웨어 요구사항은 이를 실현하기 위한 구체적이고 검증 가능한 조건을 정의하는 것입니다. 이번 포스팅에서에서는 소프트웨어 니즈와 소프트웨어 요구사항의 의미를 설명하고, 두 ..

소프트웨어 엔지니어로서 우리는 늘 높은 품질의 소프트웨어 개발과 정해진 일정 내에 제품을 출시해야 하는 두 가지 과제를 동시에 해결해야 하는 어려움에 직면합니다. 이상적으로는 충분한 시간을 확보하여 요구사항을 철저히 분석하고, 체계적인 설계를 거쳐 코드 리뷰와 검증을 통해 완성도 높은 소프트웨어를 개발하는 것이 바람직합니다. 그러나 현실에서는 비즈니스 요구 사항에 따라 일정이 단축되는 경우가 많으며, 변경사항도 빈번할 뿐만 아니라, 이에 따라 품질을 확보하는 과정이 축소되거나 간소화되는 경우가 빈번하게 발생합니다. 이러한 일정 압박 속에서 품질을 충분히 확보하지 못한 소프트웨어가 출시되면, 이후 현장에서 문제를 일으키고, 개발자는 긴급한 버그 수정과 패치 작업에 시달리게 됩니다. 이러한 과정이 반복되면서..

자동차 산업은 지금, 기계 중심에서 소프트웨어 중심(Software-Defined Vehicle, SDV) 으로의 대전환을 맞이하고 있습니다. 차량의 성능과 기능을 결정짓는 요소가 엔진과 변속기가 아니라 소프트웨어 업데이트(OTA), 인공지능(AI), 네트워크 연결성 등의 디지털 기술이 되는 시대가 도래한 것입니다.  그러나 새로운 기술과 혁신이 도입될 때마다 반드시 따라오는 그림자가 있습니다. 바로 기술적 부채(Technical Debt)입니다. SDV 전환 과정에서 빠른 시장 대응과 개발 속도를 유지하기 위해 단기적인 해결책이 선택되는 경우가 많고, 이는 필연적으로 기술적 부채를 발생시킵니다. 그러나 기술적 부채를 단순히 코드 품질 저하나 개발 속도의 문제로만 본다면, 그 위험성을 간과하는 것입니다...

"모든 기능을 문제없이 동작하게 해 주세요!!" 언뜻 보면 완벽한 요구사항입니다.모든 기능을 구현해야 하고, 구현하는 모든 기능에 문제가 없어야 합니다.이만큼 완벽한 요구사항이 있을까요? ㅎㅎ 안타깝지만, 이게 최근까지도 현실에서 심심찮게 볼 수 있는 농담같은 진담이었습니다.이번 포스팅에서는 요구사항 작성시 발생하는 일관성과 모호성을 예방하기 위한 방안으로Easy Approach to Requirements Syntax (EARS)에 대해 살펴 보고자 합니다. 관련글 보기ISO/PAS 8800: AI 안전 요구사항 도출 (Derivation of AI Safety Requirements)명확한 요구사항 작성 (모호성 제거) - 시각적 요구사항 정의, 모델기반 요구사항 명세서 (Model-Based Req..

한가지 에피소드를 살펴 볼까요?"프로세스가 없어서 그래!"프로젝트를 진행하면서 필요한 업무가 정의되어 있지 않을 때, 흔히들 "프로세스가 없어서 그래!!" 라고들 합니다. 그래서 프로세스를 정의해야 한다고 하면서 절차와 담당자를 지정하고 산출물을 정의한 프로세스 문서들을 많이 만들어 냅니다. 그런 다음 열심히 설명회를 하거나 교육을 진행하며, 실무자에게 프로세스를 준수 할 것을 요청합니다. 그런데 실무에서는 너무 많은 종류의 산출물로 인해 그리고 짧은 개발일정으로 인해 프로세스가 외면 받기 시작합니다. 또한 그렇게 시간이 흘러 조직이 변경되어 프로세스에 지정된 담당자가 존재하지 않거나, 프로세스 개선이란 이름으로 중간중간 누락된 절차들을 만들어 프로세스가 변화됩니다.  이 에피소드에서는 프로세스를 단순히..

Software-Defined Vehicle(SDV)는 차량의 주요 기능을 소프트웨어로 정의하고 제어하는 자동차 개발 패러다임입니다. 또한 SDV를 설명함에 있어 소프트웨어로 정의된 여러 기능들을 하드웨어 개발과는 별개로 빠르게 개발하고 유지보수와 추가 기능 개발이 하드웨어에 종속되지 말아야 한다는 속성, 즉 하드웨어-소프트웨어 디커플링(HW-SW Decoupling)이 중요한 속성으로 강조됩니다.  이번 포스팅에서는 SDV의 핵심 속성 중 하나인 하드웨어-소프트웨어 디커플링에 대해 좀 더 자세히 알아 보겠습니다. 사실 많은 사람들이 디커플링을 소프트웨어와 하드웨어가 완전히 독립적이다 라고 오해하는 경우가 있는데, 이는 디커플링의 정확한 본질을 잘 알지 못하는데서 비롯된 문제라고 생각됩니다. 이렇게 상당..

소프트웨어 개발 조직은 일반적으로 실제 소프트웨어를 개발하고 검증하는 직접 개발 수행 조직(Project Teams)과 소프트웨어 개발을 직접 수행하진 않지만, 이를 지원하거나 관리하는 Umbrella(우산) 조직(Management Teams)으로 나눌 수 있습니다. 이 두 조직은 서로 다른 역할을 수행하면서 협력하며 소프트웨어 개발 완성도를 높이고, 효율성과 품질을 개선할 수 있습니다. 실제로는 더 많은 조직들이 각자의 역할을 가지고 소프트웨어 개발에 기여하고 있겠지만, 이번 포스팅에서는 Umbrella Organization에 대해 좀 더 자세히 살펴 보고자 합니다.관련 글 보기소프트웨어공학: 소프트웨어 유지보수성 측정 - 왜 중요할까?소프트웨어 신뢰성 개선 전략 3가지 (3 Strategies f..

최근 자동차 산업은 전기차(EV), 자율주행차, 커넥티드카, SDV, 차량용 클라우드 서비스 등이 핵심 기술로 자리 잡으며, 자동차는 이제 단순한 이동 수단을 넘어 ‘소프트웨어 중심의 플랫폼’으로 진화하고 있습니다. 이러한 변화로 인해 소프트웨어 엔지니어에 대한 수요는 증가하고 있지만, 역설적으로 고연차 엔지니어들이 설 자리를 잃어가고 있는 현상도 나타나고 있습니다. 이 현상은 기술 변화 속도, 기업의 인력 운영 전략, 그리고 개인의 역량 변화가 복합적으로 맞물리면서 발생하고 있다고 생각됩니다. 관련 글 읽기소프트웨어 엔지니어가 갖춰야 할 핵심 역량 - 소프트웨어 엔지니어는 단순 개발자가 아닙니다.자동차 제어 소프트웨어 개발에서의 나쁜 소프트웨어 엔지니어 특징과 교훈소프트웨어 개발자 생산성에 관하여소프트..

시스템 안전 분석은 점점 더 복잡해지는 현대 시스템에서 필수적인 과제가 되었습니다. 특히 소프트웨어와 복잡한 상호작용을 포함하는 시스템에서는 기존의 고장 중심 접근법으로는 충분하지 않은 경우가 많습니다. 이러한 배경에서 제안된 STPA(System-Theoretic Process Analysis)는 시스템 사고(Systems Thinking)와 제어 이론(Control Theory)을 기반으로 안전을 분석하는 강력한 도구입니다.이번 포스팅에서는 STPA의 단계별 절차와 그 특징, 그리고 이를 활용한 반복적이고 체계적인 분석 방법에 대해 알아 보겠습니다.  STPA의 단계별 절차STPA: 시스템 안전분석 - (1) 분석 목적 정의STPA: 시스템 안전분석 - (2) 컨트롤 스트럭처 모델링STPA: 시스템 ..