글

EOL 검사란? DV·PV 검증과 양산 검사는 무엇이 다를까?

이미지
“개발할 때 DV·PV 시험을 했는데, 생산라인 끝에서 왜 또 검사하나요?” AI 생성 개념도. DV는 설계 확인, PV는 양산 조건 확인, EOL은 생산 제품 검사 관점입니다. 모든 고객의 고정 단계 순서나 실제 설비 사진을 나타내지 않습니다. 신입이라면 같은 제품을 반복해서 시험하는 것처럼 보일 수 있습니다. 하지만 설계와 양산 조건이 적절한지 확인하는 일 과 지금 생산한 제품이 정해진 검사 기준을 만족하는지 확인하는 일 은 질문이 다릅니다. 이번 글에서는 EOL 검사를 전동식 냉각수 펌프(EWP) 예시로 구분해 보겠습니다. 교육용 가상 예시입니다. 아래 항목은 실제 고객 사양, 양산 검사 절차, 시험 결과 또는 승인 기록이 아닙니다. 검사 범위·조건·주기·판정 기준은 고객 요구사항과 승인된 관리계획·검사 명세를 따라야 합니다. 1. EOL은 생산라인 마지막 단계의 검사입니다 EOL은 여기서 End-of-Line 을 뜻합니다. 조립된 제품이 생산공정의 마지막 검사 단계에서 정해진 기능과 특성을 만족하는지 확인하는 활동입니다. 제품 수명 종료를 뜻하는 End-of-Life와는 다른 용례입니다. 전원이 켜지는지만 보는 검사는 아닙니다. 제품 식별, SW·설정 확인, 전기적 측정, 통신, 구동 성능, 필요한 보정이나 조정 등이 검사 계획에 포함될 수 있습니다. 모든 제품에 이 항목이 전부 적용되는 것은 아닙니다. dSPACE는 EOL 적용 분야에서 기능 시험·보정·조정을, Dewesoft는 요구사항에 따른 시험 계획과 계측·판정·추적 기록을 설명합니다. [1] [2] 2. DV·PV와 EOL은 목적과 확인 대상이 다릅니다 이전 글 자동차 개발 단계와 검증: DV/PV와 ESIR/ISIR 의 관점을 이어가겠습니다. 여기서는 DV를 설계의 적합성 확인, PV를 양산 조건에서 만든 제품과 공정의 적합성 확인으로 설명합니다. 약어의 영문 명칭과 단계 경계는 고객 개발계획의 정의가 우선 입니다. 구분 주된 질문 대상·조건의 예 남기는 근거의 예...

자동차 개발 단계와 검증: T-car·Proto·Pilot·SOP, DV/PV와 ESIR/ISIR

이미지
자동차 개발 일정표에는 차량 제작 코드, 시험, 문서 제출, 승인 일정이 함께 등장합니다. 이를 모두 같은 종류의 ‘개발 단계’로 이해하면 혼동하기 쉽습니다. 이 글은 차량 개발·제작 이벤트, 검증 활동, 제출 문서, 다음 단계 판단 을 구분해 설명합니다. 그림은 프로젝트 설명용 예시입니다. DV마다 ESIR, PV마다 ISIR을 반드시 제출한다는 회사 공통의 일대일 규칙은 아닙니다. 시험과 문서는 다른 개념이며, 실제 시점·범위·승인 기준은 고객·프로젝트 정의를 따릅니다. 1. DV/PV는 시험 관점, ESIR/ISIR은 결과를 검토하는 문서 DV는 설계가 요구된 기능·환경 조건을 만족하는지 확인하는 설계 검증입니다. PV는 양산 조건에서 만든 제품과 생산 과정이 요구 품질을 확보하는지 확인하는 관점입니다. ECU라면 양산 조립, 공정 검사, EOL 검사 등의 유효성도 관련됩니다. 엘레멘트코리아의 공개 설명에서 ESIR은 Engineering Specification Inspection Report로, 개발 시제품의 검사·시험 결과를 기술적으로 검토하는 보고서입니다. ISIR은 Initial Sample Inspection Report로, 초도 샘플의 치수·재료·기능 등의 적합성을 정리해 고객 검토에 사용하는 보고서입니다. 이 명칭은 해당 공개 해설의 용례이며, 실제 명칭·대상·승인 범위는 고객 문서 정의를 확인해야 합니다. 이 글의 흐름은 DV 수행 → ESIR 제출·검토 , PV 수행 → ISIR 제출·검토 로 읽으면 됩니다. 이 순서는 설명용 예시이며 모든 회사의 필수 제출 규칙은 아닙니다. DV=ESIR, PV=ISIR도 아닙니다. 문서에는 여러 검사·시험의 근거가 모이고, 고객은 보완 자료나 추가 검증을 요구할 수 있습니다. 또한 DV와 PV를 구분한다고 시험을 정확히 두 번만 하는 것은 아닙니다. 사전 검증, 문제 수정, 변경 영향 평가와 재시험이 반복될 수 있습니다. 2. 차량 개발·제작 코드: 무엇을 만들고 확인하는가? 단독 M...

FMEA 실무 ⑤: 고쳤다고 끝이 아니다, 시험과 종결까지

이미지
고장·리스크 분석 · FMEA 실무 시리즈 5/5 처음 읽는 분은 ① FMEA 첫걸음 부터 차례로 따라오세요. 앞선 글에서 용어와 SW 한 행, 현재 관리, AI 활용, 평가와 조치를 살펴봤습니다. 이제 “코드를 고쳤습니다” 다음에 무엇을 남겨야 하는지 같이 보겠습니다. 처음 맡았다면 완료 칸부터 채우기보다, 다른 사람이 그 변경을 확인할 수 있는지 생각해 보세요. 아래는 가상 냉각용 전동 펌프의 SW 일부만 다룬 교육 예제입니다. 수치·버전·관측값은 실제 차량 사양이나 실행·승인 기록이 아닙니다. 1. FMEA 한 행으로는 코드를 고칠 수 없습니다 우리 행의 문제는 ‘새 메시지가 없어도 과거 명령을 유효하다고 판단하는 것’입니다. FMEA 행은 원인·고장모드·영향과 관리, 조치를 연결하는 분석 기록 이지 상세 설계서나 시험 명세서가 아닙니다. ‘타임아웃 개선’만 적어서는 개발자와 시험자가 서로 다른 동작을 떠올릴 수 있습니다. 그래서 조치를 확인 가능한 요구사항 으로 풀어 씁니다. ms는 밀리초, 1초의 1,000분의 1입니다. 마지막 유효 수신 시각을 저장하고, 현재 시각에서 그 시각을 뺀 경과시간을 비교합니다. 메시지 개수를 세어 100ms를 대신하는 것이 아닙니다. 정상 상태: 받은 유효 명령을 선택합니다. CMD_NORMAL은 이 정상 선택을 표시하는 예제 이름이며, 고정된 회전수 값이 아닙니다. commandValid는 명령이 유효하면 1, 무효하면 0입니다. 이미 통신 무효 상태라면 메시지 하나가 들어왔다고 곧바로 정상으로 돌아가지 않습니다. 무효화: 마지막 유효 수신 후 100ms 이상이면 첫 유효성 태스크에서 commandValid=0, selectedCommand=CMD_BACKUP으로 바꿉니다. 앞 변수는 명령의 유효 여부, 뒤 변수는 실제 선택한 명령입니다. 복귀 대기: 유효 메시지 3개를 연속으로 받고, 각각의 수신 간격이 100ms 미만이어야 합니다. 그 뒤 첫 태스크에서 정상 복귀합니다. 메시지의 CRC·카운터...

FMEA 실무 ④: S·O·D 점수보다 먼저 생각할 것과 개선 조치

이미지
고장·리스크 분석 · FMEA 실무 시리즈 4/5 처음 읽는 분은 ① FMEA 첫걸음 부터 차례로 따라오세요. 고장 분석 한 행을 적고 나면 점수 칸이 눈에 들어옵니다. “일단 중간쯤 적으면 될까요?” 하고 싶어질 수 있어요. 그때는 숫자 대신 질문부터 적어 보세요. 무엇이 얼마나 문제인지 설명하지 못한 점수로는, 다음에 무엇을 바꿔야 할지도 정하기 어렵습니다. 이번에도 가상 EWP(전동식 냉각수 펌프)의 SW 명령 유효성 관리 일부를 사용합니다. 실제 시험·안전성·승인을 입증하는 사례가 아닙니다. 평가 기준이 제공되지 않았으므로 점수와 조치 우선순위는 정하지 않습니다. 1. S·O·D는 서로 다른 질문입니다 S(심각도) 는 “이 영향이 생기면 얼마나 심각한가?”입니다. 과거 명령을 유효하다고 잘못 판단하면 현재 냉각 요구와 다른 펌프 명령이 유지될 수 있지요. 여기서 차량에 미칠 최종 영향과 운전 조건을 시스템 담당자와 확인해야 합니다. 시험을 많이 한다고 영향의 심각성이 저절로 줄어들지는 않습니다. O(발생도) 는 “현재 예방 관리 아래에서 이 원인이 발생할 가능성을 무엇으로 판단할까?”입니다. 우리 원인 후보는 새 수신이 없어도 유효 플래그를 유지하는 상태 갱신 로직 오류입니다. 상태·시간 요구가 빠져 있지는 않은지, 설계 방법과 검토가 그 오류를 막는지 확인해야 합니다. SW가 자주 실행된다고 O가 높아지는 것은 아닙니다. 코드 실행 횟수나 메시지 수신 빈도는 설계 오류가 만들어질 가능성과 다릅니다. 입력 상황이 오류를 드러낼 기회와 오류 원인의 발생도도 구분하세요. 실제 프로젝트 기준이 요구하는 설계·예방 근거를 보고 판단합니다. D(검출도) 는 “현재 개발 단계 검출 관리로 이 원인이나 고장을 찾아낼 수 있을까?”입니다. 정상 통신 시험만으로 메시지가 끊긴 뒤 과거 명령을 계속 선택하는 오류까지 찾을 수 있다고 말하기 어렵습니다. “정상 통신 시험”이라는 이름만 보지 말고, 메시지를 끊어 보았는지, 유효 플래그와 선택 명령을 읽었는지...

FMEA 실무 ①: 시스템·HW·SW FMEA와 핵심 개념

이미지
고장·리스크 분석 · FMEA 실무 시리즈 1/5 “FMEA 표를 받았는데, 첫 칸부터 뭘 써야 할지 모르겠어요.” 처음이라면 자연스러운 질문입니다. 표의 빈칸을 한꺼번에 채우려 하지 마세요. 먼저 제품이 해야 할 일 하나를 고르고, 그 일이 잘되지 않는 모습을 문장으로 써보면 됩니다. 이번 글은 전동식 냉각수 펌프를 예로 들어 그 첫 문장을 함께 만들어봅니다. 대화와 분석 내용은 교육용 가상 예시이며, 실제 고객 자료나 시험 기록은 아닙니다. 고장 보고서가 아니라, 설계에 미리 던지는 질문 FMEA(Failure Mode and Effects Analysis)는 ‘고장모드 및 영향 분석’입니다. 아직 고장이 나지 않았어도 “어떤 식으로 일을 못 할 수 있고, 그러면 무엇이 달라질까?”를 살펴보는 활동이지요. 고장 보고서가 이미 생긴 문제를 조사한다면, FMEA는 설계 중에 실패 가능성을 찾아 예방할 기회를 만드는 쪽에 가깝습니다. 실제 고장 사례도 참고할 수 있습니다. 왜 하느냐고요? 표나 점수를 만드는 것이 목적은 아닙니다. 고객에게 문제가 생기기 전에 설계·공정의 실패 가능성을 찾아, 무엇을 바꾸고 시험할지 정하는 것 입니다. 새 명령이 끊겼는데 펌프가 옛 명령을 계속 쓸 가능성을 일찍 알면, 시간 조건을 설계와 시험에 반영할 수 있습니다. 변경이 어려워지기 전에 개선하는 것이지요. 다만 FMEA 자체가 무고장이나 안전 승인을 보장하지는 않습니다. 이번 예제의 EWP는 Electric Water Pump, 즉 전기로 구동하는 냉각수 펌프입니다. 냉각수를 순환시켜 냉각 기능을 돕습니다. 제어기는 펌프를 어떻게 움직일지 명령을 받고, 그 명령을 사용할 수 있는지 판단합니다. 정상 흐름을 아주 작게 그리면 ‘냉각 요구 → 펌프 명령 수신 → 명령 유효성 판단 → 모터 구동 → 냉각수 순환’입니다. 실제 제품의 구조와 조건은 설계 자료로 확인해야 합니다. 명령을 받아 냉각수를 보내는 정상 기능을 단순화한 그림입니다. 실제 구조는 설계 자료로 확인합...

FMEA 실무 ②: EWP 제어기 고장 분석을 검증 테스트로 연결하기

이미지
고장·리스크 분석 · FMEA 실무 시리즈 2/5 처음 읽는 분은 ① FMEA 첫걸음 부터 차례로 따라오세요. 지난 편에서 ‘통신두절’이라는 짧은 말을 원인·고장모드·영향으로 풀었습니다. 이번에는 전동식 냉각수 펌프(EWP)의 소프트웨어(SW) 분석표 한 줄을 함께 채워보겠습니다. 숫자나 점수보다 먼저 볼 것은 문장 사이의 연결입니다. 아래 내용과 기존 검토·시험은 교육용 가상 예시이며, 실제 수행 결과가 아닙니다. 먼저 ‘무엇을 하는 부분인가’를 적습니다 “펌프 전체를 한 줄에 쓰면 될까요?” 오늘은 범위를 조금 줄여보겠습니다. 대상은 명령 유효성 관리 , 기능은 ‘수신 명령의 유효성 판단·무효화·복귀’입니다. 명령을 받는 것만이 아니라, 오래된 명령을 더 이상 쓰지 않게 하고 조건이 충족되면 정상 상태로 돌아오는 일까지 포함합니다. 요구사항 칸에는 이 기능을 정한 문서를 연결합니다. 이번 가상 요구는 정상 상태의 명령 선택, 마지막 유효 수신 후 시간이 지났을 때의 무효화와 대체 명령 선택, 연속 유효 수신 후 복귀를 다룹니다. 대체 명령은 정상 명령을 쓸 수 없을 때 선택하도록 상위 시스템이 정할 명령입니다. 어떤 값이 적합한지는 별도 확인 대상입니다. 정확한 시간과 판정 조건은 5편에서 시험으로 연결하겠습니다. 분석 행에는 EX-FMEA-SW-01 이라는 이름표를 붙입니다. 이것이 행 ID입니다. 나중에 같은 줄의 설계 변경과 시험을 찾기 위한 표시일 뿐, 고장 내용을 대신하지는 않습니다. 이제 아래 세 칸을 읽어보세요. 원인 후보 새 수신이 없어도 유효 플래그를 유지하는 상태 갱신 로직 오류 후보 고장모드 유효하지 않은 과거 명령을 계속 유효하게 판단 영향 현재 냉각 요구와 다른 펌프 명령 유지 → 상위 냉각 기능 영향 가능 유효 플래그는 명령을 사용할 수 있다고 표시하는 값입니다. 새 메시지가 없는데도 이 값을 바꾸지 않는 처리 오류가 있다면, 오래된 명령이 계속 유효하다고 판단될 수 있겠지요. 그래서 원인에는 처리 오류의 후보...

FMEA 실무 ③: 외부 컨설팅 없이 AI로 작성하는 방법과 프롬프트

이미지
고장·리스크 분석 · FMEA 실무 시리즈 3/5 처음 읽는 분은 ① FMEA 첫걸음 부터 차례로 따라오세요. 2편에서 EWP(전동식 냉각수 펌프)의 고장 분석 한 행을 만들었지요. 이제 AI에 맡기면 금방 끝날까요? 문장을 정리하는 데는 도움이 됩니다. 다만 잘 정돈된 문장이 맞는 분석이라는 뜻은 아닙니다. 처음에는 AI 없이 한 행을 설명해 본 뒤, 놓친 질문을 찾는 용도로 써 보세요. 이번 내용은 가상 EWP의 일부 기능을 다루는 교육 예시입니다. 실제 시험이나 승인 기록이 아니며, 완성된 FMEA도 아닙니다. 1. AI를 켜기 전에, 내가 설명할 수 있어야 할 것 선배가 먼저 물을 질문은 “이 기능이 무엇을 해야 하죠?”입니다. 담당자는 수신 명령이 언제 유효하고, 언제 무효로 바뀌며, 언제 정상으로 돌아오는지 알아야 합니다. 그다음 “어디까지가 우리 SW이고, 잘못되면 상위 냉각 기능에 어떤 영향을 줄까요?”를 설명해 보세요. 차량 최종 영향까지 모르겠다면, 그 부분은 시스템 담당자에게 확인할 질문입니다. 준비할 자료는 요구사항과 설계의 기준 버전, 실제로 수행한 검토·시험의 근거입니다. 자료를 붙였다고 검토가 끝나는 것은 아닙니다. 현재 관리가 어떤 원인이나 고장을 다루는지, 다루지 않는 범위는 무엇인지 사람이 읽어야 합니다. 아래처럼 짧게 시작해도 괜찮습니다. 교육용 입력, 실제 승인 사양 아님 기능: 수신 명령의 유효성 판단·무효화·복귀 고장 후보: 유효하지 않은 과거 명령을 계속 유효하게 판단 원인 후보: 새 수신이 없어도 유효 플래그를 유지하는 상태 갱신 로직 오류 영향 후보: 현재 냉각 요구와 다른 펌프 명령 유지 → 상위 냉각 기능 영향 가능 조건: 새 메시지가 정해진 시간 동안 없으면 과거 명령을 무효화하고 대체 명령을 선택 복귀: 사양에 정한 연속 유효 수신 조건으로 정상 복귀 시간·횟수의 구체 값: 이 입력에는 제공하지 않음. 추측하지 말고 요구사항 원문을 확인 현재 관리: 요구 검토와 정상 통신 시험만 제시됨(둘 다 ...