본문 바로가기

System & Software Engineering

E/E 아키텍처 설계에서 고려해야 할 사항 급변하는 자동차 산업에서 차량 제어는 날이 갈수록 더 정교해지고, 차량 내외부 시스템과의 연결도 고도화되고 있습니다. 이러한 복잡성의 증가는 차량 전기 및 전자(E/E) 아키텍처 설계에 많은 도전과 과제를 가져오고 있습니다. 이번 글에서는 차량 E/E 아키텍처를 개발할 때 직면하는 주요 도전과 고려 사항을 자세히 다루고, 이러한 문제를 해결하기 위해 사용될 수 있는 기술과 방법을 소개합니다. 차량 복잡성의 증가현대 차량의 복잡성 증가는 잘 알려진 사실입니다. 전기 및 전자 콘텐츠가 빠르게 증가하고 있으며, 연결된 차량 기능이 모든 카테고리와 세그먼트에서 채택되고 있습니다. 이로 인해 더 강력한 스마트 기능이 통합되고 있으며, 이러한 고급 기능은 모두 전기 배선과 전자 부품에 의존합니다. 이러한 증가하는 .. 더보기
소프트웨어 정의 차량 (SDV, Software Defined Vehicles) 추진 전략 비교 SDV 추진 배경최근 여러 자동차 회사들이 소프트웨어 정의 차량(SDV, Software Defined Vehicles) 즉, 소프트웨어에 의해 차량의 기능과 성능을 결정할 수 있는 개념을 가진 차량 개발에 대한 여러 전략과 방향을 앞다퉈 발표하고 있습니다.이는 테슬라라는 걸출한 OEM의 등장으로 핫한 이슈가 되고 있는 자율주행 기술의 발전, 이를 지원하기 위한 커넥티드카 및 커넥티드카 지원 인프라의 증가, 그리고 내연기관을 체하는 새로운 동력원으로의 전기차, 사용자의 경험과 자동차의 성능과 기능을 크게 개선하기 위한 기술로서의 무선업데이트(OTA, Over The Air)의 중요성, 마지막으로 차량에서 수지보디는 데이터 분석 및 활용이 매우 중요한 배경이 되고 있다 할 수 있습니다. 이러한 배경의 이.. 더보기
소프트웨어 개발자 생산성에 관하여 이 글은 2023년 IEEE Software Magazine에 등재된 "A Human-Centered Approach to Developer Productivity"를 기반으로 작성되었습니다.  소프트웨어를 개발하는 사람을 흔히 "개발자"라고 부릅니다.소프트웨어 공학적 관점에서 보았을 때, 소프트웨어 개발에 관여하는 수많은 이해관계자들이 있고, 이들은 각기 다른 역할(Role)을 부여하고 있음에도 불구하고, 우리나라에서는 "개발자"라는 말로 모두 "퉁"쳐서 지칭하고 있으며, 실제 업무에서도 이들 "개발자"에게 모든 책임(Responsibility)을 전가하여 과중한 업무로 내몰고 있는게 현실이라고 생각됩니다.  이는 소프트웨어 개발에 대한 생산성과 직접적인 연관성이 있을 것이며, 개발자 생산성은 IT 산.. 더보기
SW FMEA의 Ground Rules SW-FMEA를 시작하기 전에, 그라운드 룰이 무엇인지를 결정할 필요가 있다.어떤것이 맞는것인지 어떤것이 틀린것인지에 대한 원칙은 없지만, SW-FMEA를 수행함에 있어(1) 어떤 고장을 고려할 것인지,(2) 어떤 종류의 고장을 포함할 것인지,(3) 고장 허용 수준은 어느정도로 할 것인지 등의 정보를 사전에 고려해야만 한다. SW FMEA Ground Rules (Example)특정 레벨에 대한 모든 고장들이 식별되어야 한다. (SW FMEA의 범위 식별)가령 컴포넌트 레벨에 대한 모든 고장을 식별한다든지 또는 서브 시스템의 모든 고장 혹은 소프트웨어 레벨의 모든 고장을 식별할 것인지를 결정해야 한다.특정 레벨에서 어떤 고장이 존재하는지가 식별되어야 한다. (잠재 고장 모드 식별)소프트웨어가 의도된 기능.. 더보기
소프트웨어 진화와 아키텍처 트레이드 오프 (Software Evolution and Architecture Trade-Off) 소프트웨어 아키텍처는 인생처럼 불완전한 정보와 시간 압박 속에서 수많은 상황과 제약에 따른 트레이드 오프 결정을 내리는 과정입니다. 완벽한 소프트웨어 아키텍처를 찾으려는 팀은 실망할 가능성이 높지만, 완벽하지 않더라도 다른 대안이 없다면, 어쩔수 없는 트레이드 오프 결정을 내려야 할 때가 많습니다. 예를 들어, 진화할 수 없고 유지 보수가 어려운 취약하고 비용이 많이 드는 시스템이 그렇습니다. 또한 여러 이해관계자들의 다양한 니즈를 충족시켜야 한다는 점에서도 트레이드 오프 결정이 필요한 경우가 많습니다. 특히, 소프트웨어 아키텍처 결정 시점에 수많은 품질 속성 요구사항이 존재하지만, 모든 품질 속성 요구사항을 만족시킨다는 것은 현실적으로 불가능하기 때문에 역시 트레이드 오프가 필요합니다. 그외에도 트레이.. 더보기
Software Isolation During the Software Refactoring 최근 3~4년간 시간들을 돌이켜보면 소프트웨어 관련 기술들을 실무에 적용하기 위해 상당한 시간을 들였던 것으로 기억합니다. 소프트웨어를 개발하는 조직에서 소프트웨어 엔지니어로 살기 위해 여러 케이스를 고려한 나름의 노력이었는데, 안타깝지만 성과는 크지 않았던 것이 현실이었습니다.이런 무성과? 저성과?의 이유를 생각해 보면, 결국 조직적 이슈였던거 같은데 지속적으로 소프트웨어를 개발하고 유지보수하는 업무를 단순화 그리고 효율화하기 위한 노력이 왜 조직적 이슈로 인해 무산(?) 되었을까.. 그리고 무엇이 이러한 조직적 이슈를 야기시키고 있는 것일까 생각해 봅니다. 결국 생각해보면, "소프트웨어에 새로운 기능이 요구되고, 시간이 지남에 따라 복잡해지고 (예를 들어 불필요한 종속성, 중복되거나 강하게 결합된 기.. 더보기
MBSE (Model Based System Engineering) Model Based System Engineering (MBSE)MBSE란 복잡한 시스템의 요구사항, 설계, 분석, 검증 및 확인을 지원하는 정형화된 방법론으로 코드나 문서 기반의 기존 개발 방식과는 달리 개발하고자 하는 대상 즉, 시스템 자체를 하나의 모델로 간주하며, 컴퓨팅 환경의 발전으로 MBSE를 많은 산업군에서 활발하게 채택하고 있습니다. 이는 기존 코드나 문서 기반 개발 방식에서는 전통적 개발 프로세스를 따르는 경우, 최종 아웃풋이 나오기까지 많은 시간과 노력이 필요한 반면, 전통적 개발 프로세스를 따르지 않는 경우, 급변하는 환경/법규/규정 등을 만족하기 어려울 수 있다는 점도 한몫 한다고 생각합니다. 실제 NASA에서는 2020년 1월 MBSE가 시스템 복잡성을 추적하기 위한 수단으로.. 더보기
Software Product Line (SPL) 소프트웨어 제품 라인의 정의소프트웨어 제품 라인은 여러 소프트웨어 시스템이 공통의 관리된 기능 세트를 공유하여 특정 시장 또는 임무의 필요를 충족하는 것을 의미합니다. 이 시스템들은 공통의 핵심 자산에서 개발되며, 이는 재사용 가능한 구성 요소, 아키텍처, 도구, 프로세스, 인력의 지식 등을 포함합니다. 소프트웨어 제품 라인의 주요 개념1. Core Assets정의: 여러 제품에 사용되는 재사용 가능한 아티팩트 또는 리소스예시: 아키텍처, 소프트웨어 구성 요소, 요구 사항 명세서, 테스트 계획, 도메인 모델, 문서, 도구, 프로세스.2. 재사용 전략소프트웨어 제품 라인은 재사용을 전략적으로 계획하고 조직 전체에서 이를 실행하는 것을 포함한다. 이는 단순한 코드 재사용을 넘어 시스템 수준에서의 재사용을 의.. 더보기

티스토리툴바