미정

시스템 요구사양서에 internal input out을 정리하는 표가 있는데 거기에 Characteristic이라는 카테고리가 있는데 'power', 'logic', 'analog', 'internal signal' 등이 있는데 여기서 logic이 도대체 뭐야? 그리고 애초에 internal의 input output을 정리하는 표인데 internal signal로 따로 중복된 말처럼 분류하는건 뭐야? 시스템 요구사양서(SRS)나 설계 문서에서 Characteristic(특성) 항목은 해당 신호가 물리적으로나 논리적으로 어떤 성질을 갖는지를 정의합니다. 질문하신 두 가지 의문에 대해 실무적인 관점에서 답변해 드리겠습니다.1. 'Logic' 신호란 무엇인가?여기서 Logic(로직)은 신호의 전압 수치가 중요..

어떤 것을 이루기 위해서 PWM을 사용하는 건데? 즉 PWM의 특징이 다른 신호와 비교해서 어떤데? 자동차에서 PWM(Pulse Width Modulation)을 사용하는 가장 큰 목적은 디지털 환경에서 아날로그 장치(모터, 램프 등)를 고효율로 정밀하게 제어하기 위해서입니다. 전통적인 아날로그 신호나 가변 저항 방식과 비교했을 때, PWM은 다음과 같은 압도적인 특징과 장점을 가집니다. 1. 극대화된 에너지 효율 (저전력 소비) 아날로그 방식: 전압을 낮추기 위해 저항을 사용하면, 줄어든 전압만큼의 에너지가 열로 소모되어 낭비됩니다.PWM 방식: 스위치를 완전히 켜거나(ON) 완전히 끄는(OFF) 동작만 반복합니다. 꺼져 있을 때는 전류가 흐르지 않고, 켜져 있을 때는 저항이 거의 없어 열 발생과 에너..

ISO 26262의 표준을 준수하여 개발을 한다고 할 떄, HW 엘리먼트 평가라는 활동이 있자나? (Class 1, 2, 3으로 나누어서 평가하는 것) 이 활동이 HW 요구사양 작성보다 훨씬 나중에 이루어지는게 타당하다고 보이니? 네, ISO 26262를 준수하는 개발에서 HW element evaluation (하드웨어 엘리먼트 평가, ISO 26262-5:2018 Annex E 또는 Clause 8/9 관련 내용으로, Class 1/2/3 분류)은 HW 요구사양(Hardware Safety Requirements Specification) 작성보다 훨씬 나중에 이루어지는 것이 타당합니다. 오히려 그 반대가 비표준적이고 위험합니다.왜 HW element evaluation이 HW 요구사양보다 늦게 이..

시스템 요구사양서, 시스템 아키텍처 설계서 같은 이런 개발 문서들은 변경이력이 있을 때 그 변경한 부분에 대해서 문서 내의 History 부분에 쓰는데, 변경한 내용에 대한 서술 방식이 너무 단순해서, 정확히 어떤 부분을 변경했는지, 그리고 왜 변경했는지 이유를 알기가 어려워. 이럴 경우 어떻게 해야 돼? 네, 기능안전(ISO 26262) + ASPICE 프로젝트에서 시스템 요구사양서(SRS), 시스템 아키텍처 설계서(SAD) 같은 문서의 History / Revision History / Change History 섹션이 "버전 업 → 날짜 → 작성자 → 변경" 정도로만 단순하게 적혀 있으면 정말 문제입니다. 나중에 감사(audit)나 assessment 시 assessor가 "이 변경이 Safety ..

시스템 요구사양서에 커넥터 PIN 입력 정보와 출력 정보를 써야해? 안써도 된다면 안써도 된다고 말해주고 만약 써야 한다면 왜 써야 하는지 알려줘 시스템 요구사양서(System Requirements Specification, SYS.2 출력물)에 커넥터 PIN 입력/출력 정보를 반드시 써야 하는 것은 아닙니다. 안 써도 된다고 말할 수 있어요.왜 안 써도 되는가? (주요 근거)Automotive SPICE PAM 4.0 SYS.2의 목적과 BP 내용SYS.2는 stakeholder requirements를 기반으로 system-level functional & non-functional requirements 를 지정·분석·구조화하는 프로세스입니다.SYS.2.BP1 (Specify system requ..

근데 시스템 아키텍처가 설계서 문서가 아니라 그 상위 문서인 시스템 요구사양서 문서에 system state descripiton 카테고리에 initialization state, normal state, wating sleep state, sleep state로 나누어서 각 state마다 그 상태에 대한 설명과 검증 기준을 명세했고, System transition description 카테고리에 Transition_initialization mode, Transition_normal mode, Transition_waiting sleep mode, Transition_sleep mode로 나누어서 각 천이 조건에 대한 설명과 검증 기준을 명세했거든? 그랬을 때 각 system mode에 대한 것을 하..

SYS.3 BP2의 그 문장 마지막 부분 "in different system modes" 가 정확히 무엇을 의미하는지 실무 관점에서 명확히 설명해 드릴게요."different system modes"란?→ 시스템(또는 ECU)이 작동하는 서로 다른 상태/모드(mode) 를 말합니다. 자동차 시스템은 항상 "하나의 상태"로만 동작하지 않고, 상황에 따라 완전히 다른 행동 패턴을 보이기 때문에, 이 모드마다 시스템 요소(system elements)들의 행동(behavior) 과 상호작용(interaction) 이 달라진다는 걸 문서화하라는 뜻입니다.ASPICE PAM 4.0에서 이걸 요구하는 이유는:정적 설계(구조, 인터페이스)는 SYS.3 BP1에서 다루지만,동적 측면(dynamic aspects) 은..

요구사항 description이 다음과 같이 표현이 되어 있다. - Element Specification[기능1] : Power(B+) Input Control CFC 전원(B+)을 각각의 element에 안정적으로 공급하는 기능을 수행 한다.└ Input Range : 0 ~ 24V└ Voltage supply : 5V- Element Type : H/W 여기서 나의 질문시스템 아키텍처 설계서에서 각 엘리먼트에 대한 설명 부분을 읽고 있는데, B+ 전원을 각각의 element에 안정적으로 공급하는 역할의 엘리먼트에 대한 설명 부분이거든? 근데 여기서 설명으로 Input range : 0 ~ 24V', 'Voltage supply : 5V' 로 되어 있는데, 내가 이 둘의 차이점을 해석해보려고 하는데..

EARS는 요구사항을 명확하고 간결하게 작성하기 위한 문법적 접근법이고, MBSE는 모델을 중심으로 시스템 요구사항과 설계를 관리하는 방법론입니다. 두 방법은 모두 요구사항의 모호성을 줄이고 추적성을 높이는 데 목적이 있지만, 접근 방식이 다릅니다.🔎 EARS (Easy Approach to Requirements Syntax)정의: “쉬운 요구사항 문법 접근법”으로, 요구사항을 일정한 문장 패턴으로 작성해 모호성을 줄이는 방법.핵심 아이디어: 요구사항을 상황별 템플릿으로 나눠 작성.장점:적용 분야: 자동차, 항공, 의료기기 등 안전·품질이 중요한 산업에서 요구사항 문서화에 활용.⚙️ MBSE (Model-Based Systems Engineering)정의: 문서 중심이 아닌 모델 중심으로 시스템 엔지..

자동차 제어기(ECU) 시스템 개발에서 시스템 아키텍처 다이어그램에 보이는 Panel이라는 엘리먼트는 보통 **운전자 인터페이스(HMI, Human-Machine Interface)**를 의미합니다. 즉, 제어기가 직접 다루는 센서·액추에이터 같은 하드웨어 요소가 아니라, 운전자에게 정보를 표시하거나 운전자가 입력을 주는 장치를 나타내는 경우가 많습니다.🔎 자동차 제어기 시스템 아키텍처에서 Panel의 의미계기판/클러스터(Instrument Cluster): 속도계, RPM, 경고등, 메시지 표시창 등 운전자에게 상태를 보여주는 부분.센터 패널(Center Console Panel): 인포테인먼트, 공조 제어, 터치스크린 등 운전자가 직접 조작하는 인터페이스.HMI 요소: 버튼, 스위치, 디스플레이, ..