오토모티브 산업에 진입을 고민 중인 사장님이 계시다면

오토모티브 산업에 진입을 고민 중인 임베디드 분야 사장님이 계시다면 이 글이 참고가 될 수도 있으리라 봅니다.

수년전 선행 및 실차 양산 a-z까지 뛰어본 경험으로 작성된 글이며 우리나라 환경과 맞지 않을 수도 있습니다.

대략 병 내지 정 정도 되는 하청 업체 분들에게 이글을 추천드립니다.

 

오토모티브, 즉 자동차 산업은 IT가 아니라는그런 느낌이 다소 있습니다.

공장에서 부품을 뽑아내고 그 부품을 공급하고 이런 산업이라는 이미지가 어느정도 있는 것 같습니다.

하지만 자동차 산업은 점점 더 IT화 되가고 있으며 오토모티브에 발을 담근 이력이 없으시거나 단순하게 생각하는 경우 상당히 골치 아픈 일이 될 수 있으므로 멘땅헤딩 진입을 별로 추천드리지 않습니다.

 

정말 간단한 동작을 하는 파트가 있습니다.

너무 간단한 동작을 합니다. 별로 복잡한 것도 없어보입니다.

그거 별거 아닌거 같은데 만들어서 납품 뚫으면 대박나겠는데? 라고 생각할 수 있습니다.

문제는 자동차가 돌아댕기는 환경이 예상외로 무쟈게 험악하다는점입니다.

 

1. 고온 문제

불지옥 대한민국 한여름에 야외 주차된 차량이 어떻게 되는지 잘 아시리라 봅니다.

그 뙤약볕에 달궈지면 갑자기 칩들이 오동작을 합니다.

온도 스펙 맞는 제품 쓰면 되는거 아니냐? 라고 생각하겠지만 네 맞습니다. 그런데 단가도 올라가고 항상 100%의 신뢰도를 갖는 것은 아닙니다. 제품이 동작 한다/안 한다의 개념이 아니라 동작을 가끔 안한다 이런 골치아픈 문제가 생기게 됩니다. 온도 테스트는 후반부에 진행하는데 기능 개발 다 해놓고 후반부 와서 온도로 빠꾸 맞으면 사장님 하늘이 노랗게 되는 멋진 모습을 보실 수 있으십니다. HW 보드 설계 다시 해야할 가능성도 있거든요

 

2. 저온 문제

4계절이 뚜렷한 우리나라 겨울에는 블리자드가 폭풍치는 저온환경이 되면 각종 센서들이 헛짓을 합니다.

온도 스펙...? 맞는데 캘리브레이션이 문제네?

센서가 온도를 다 지원하는데 온도마다 각기 다른 동작 캘리브레이션이 필요하네?

 

그리고 저온의 가장 큰 문제는 추웠다가 낮이 되면서 따뜻해지면 혹은 제품이 동작하면서 발열이 발생하면 이슬이 생기거나 하는데 매우 골치가 아픕니다. 컴퓨터 시끄럽고 발열이 심하다고 겨울에 베란다에 내놓고 사용하면 이슬 때문에 맛가는거 아시죠?

 

3. 습도 문제

사막에 가서 필드 테스트 돌립니다. 이건 뭐 크게 문제가 안되는데 엄청 습한 환경, 염도가 많은 환경은 문제가 될 수도 있습니다. 우리나라 좋은 나라 장마(X),  우기(O)가 있는 나라, 내륙도 아니라 바다가 있어 염도도 신경 써야 하는 나라 ㅎㅎ

에이 이양반 뭘 모르는구만 그냥 PCB에 몰딩액 쫙 뿌려서 코팅해버리면 되

-> 몰딩액이 1, 2번 문제와 맞물려서 트러블을 일으키는 케이스를 보셨는지요 ㅎㅎ

열팽창 수축에 의해 몰딩액이 bga 타입 칩 아래로 흘러 들어가서 냉납 비슷한 현상을 발생시키거나 저항을 정말 미세한 힘으로 조금씩 아주 천천히 밀어버리거나!! 심지어 열 발산을 안하고 그대로 가지고 있거나 ㅎㅎ 이쯤되면 환장을 하게 됩니다.

게다가 건강에 문제가 있을 수 있는 제품이라면 양산할 때 취급 관리도 골치아프고 :)

이런 부분에 경험이 없으시면 당황하실 수 있으리라 봅니다.

 

4. 전자파

이게 좀 골치 아픕니다.

그냥 개발하는 환경에서는 잘 동작해요

별 어려운 기능이 아니에요 복잡한 일을 하는 것도 아니구요 그래서 보통 사업 시작하려고 하면 그거 무쟈게 간단한건데 그렇게 단가가 높아? 어이가 없네, 내가 나서겠다! 이런 스토리로 시작을 하는 케이스가 있나봅니다.

그런데 칩이 오토모티브 AEC-Q100 받았는데 자동차 안에 들어가서 돌리면 오동작을 하네요?

웃긴데 진짜 그렇습니다.

자동차 내부에 보이지 않는 전자파가 어마어마 한가봅니다.

단순히 램에 있는 데이터만 깨지는 게 아니라 레지스터 값도 바뀌고 PC 값도 바뀌고 인터럽트도 지 맘대로 발생하고 좀 골치 아픕니다.

케이스로 쉴딩도 잘 해야 하지만 칩 자체에서 제공하는 ESD 관련 fail safe나 기타 작업들을 신경써서 해야 합니다

SW 개발자도 신경 써야 합니다 :)

당연히 HW 개발자는 I/O 라인 설계도 이런 요소들 다 생각해야 하구요

테스트 할 때 건으로 쏴대면 칩이나 보드가 운명하는 것을 고려하여 충분히 수량을 뽑아놓아야 합니다.

 

5. 저전력

절전 모드에 대한 SW 및 HW 설계를 잘 하셔야 합니다.

SW 개발자들이 간과하는 부분이 있는데 HW는 OFF 처리하면 하나 둘 셋 으쌰 하고 바로 전류 값이 떨어지는 게 아니라 천천히 방전되는 그래프를 그리며 변동 됩니다.

더불어 사용하지 않는 HW에 대한 핀 상태 처리 및 sleep & wake up 트리거링에 대한 HW 전압레벨 그래프와 타이밍을 잘 맞추는 등의 작업이 진지하게 이뤄져야 합니다.

실차에서는 예상하지 못했던 CAN 통신이 더 들어온다거나 등의 요소들이 있으므로 이런 부분에 대한 대비도 필요합니다.

MCU 레벨에서 BOD나 ESD에 대한 flag, period에 대한 설정을 하는 부분이 있으니 확인하시기 바랍니다.

HW 전원 블럭 설계 관련하여 어떤 소자를 쓰느냐에 따라 전압, 전류값 떨어지는 속도가 다를 수 있으니 이런 부분도 고려가 필요할 수 있습니다.

 

6. 코딩룰

4번의 이유나 기타 여러 이유로 안정성을 위해 여러 코딩룰 체크를 수행해야 합니다.

Misra-C나 Cert-C 등등등 동적, 정적 검증을 돌려야 합니다.

report가 나와야 하기 때문에 가짜로 할 수 없습니다. 모든 걸 justify 처리하는 건 좀 아니고 진짜 중요한 파트입니다.

특히 복잡도 처리작업 같은 것을 수행하면 리펙터링 수준까지 가기 때문에 하루 이틀내로 뚝딱 되는 일이 아닙니다.

문제는 이 작업을 수행하는 툴이 너무 비쌉니다. mathworks에서 polyspace 견적 한 번 받아보면 기절초풍을 할 것 같은 가격이 나옵니다. 호환 툴이 있긴 한데...... 저라면 polyspace 쓰겠습니다.

 

7. 전반적인 프로세스

아시겠지만 전반적인 진행 프로세스 단계가 있습니다.

그 단계 내부에 세부적인 단계도 있습니다. 그런 부분들을 미리 안다면 어느정도 일정이나 인력에 대해 대비하고 준비할 수 있습니다. 없다면....네? 갑자기 그걸 해오라구요?

 

8. 양산대응

양산하면 끝~ 이 아니라...양산공정에서 생각도 못한 문제가 발생할 수 있습니다.

SW를 어떻게 기록할 것인가 이런식의 소프트웨어 관련 이슈를 한 번 겪으시리라 봅니다.

특히 자동화가 결합되어야 한다면 :)

특히 양산하다가 장애가 발생하는 경우 엄청난 시간적 압박이 강하게 들어옵니다.

별 듣도 보도 못한 개발 외 부서에서 온간 잡 부서들과 잡 인원 및 기타 등등 알 수 없는 공장의 알 수 없는 인원들로부터 수많은 반복적인 상황 설명 및 분석 대응 설명 요청을 계속 받습니다.

이와 동시에 장애 원인 분석도 진행되어야 하며 테스트도 수행해야 합니다.

더불어서 문제현상이 발생한 제품의 시리얼 넘버 및 현재 제품이 언제 어디로 납품 되었는가, 수량이 정확하게 파악 되어야 합니다.

그리고 문제 현상을 수정한다면 제품을 모두 변경해야 하는지 업데이트로 해결이 가능한지 등의 요소들이 명확해야 하며 업데이트 혹은 교체에 소요되는 시간, 인력에 해당하는 것이 명확하게 있어야 합니다.

더불어 당장, 즉시 저 멀리멀리 하루 반나절 떨어진 곳 혹은 비행기를 타고 택시를 타고 한 참을 가야 하는 곳의 공장에 즉시 인력이 파견되어 제품 교체 혹은 업데이트 작업을 진행해야 합니다.

뭔가 공장의 인력이 친절하게 차량에서 제품 분해를 도와주고 공구도 빌려줄까요?

아니요 모든걸 완벽히 준비해가야 합니다.

공구, 인력, 작업 절차가 담긴 문서, 예비 부품, 테스트 도구, 심지어 멀티탭까지도

참고로 저는 해외로 나갈 때 릴케이블 한국에서 구비해서 갔었습니다.

 

구어체라 좀 복잡한데 진짜 다 하셔야 합니다

30분 자고 디버깅한 적도 있었고

7일간 같은 회사 양산팀과 싸우며 고객사에게 같은 내용 계속 설명했던 기억이 나네요

분위기 살벌합니다 ㅎㅎ

 

같은 회사 양산팀도 문제인데 회사 손해가 크니 진짜 원인을 밝히지 말자 묻어두고 가자 이런식으로 말하는 미친 케이스도 있습니다. 절대 이러시면 안됩니다. 진짜 나중에 고객에게 인도된 차량 직접 찾아가서 교체하고 이런식의 엄청난 상황이 나올 수도 있습니다. 비용은 당연히 배상 다 해야 합니다. 출장비 인력비 등등등

 

양산 문제 대응할 때 정확한 재현 조건 및 상황을 알 수 없는 경우가 상당히 많습니다.

그냥 증상만 전달 되는 경우가 많습니다. 가능하면 초기에 바로 연락해서 자세한 상황을 최대한 듣기를 추천드립니다.

일단 시간이 반나절 지나면 그 이후부터는 디버깅을 할 시간 조차 주어지지 않습니다.

 

만약 제품 개발도 직접 하시고 양산 공정도 직접 개발하셔야 하는 경우라면 고생이 많으시겠지만 양산 공정 단계에 대한 설계를 매우 꼼꼼하게 DB화 해서 작업하시기 바랍니다.

 

9. 인맥

환장 합니다.

어떻게든 다국적기업에 납품해서 양산라인 타면 납품한 회사의 주가에 큰 영향을 받기도 하고 그것을 하나의 세일즈 포인트로 삼을 수 있다는 것을 알기에 인맥을 타고 자신들의 제품도 한 번 써보라고 갑자기 치고 들어오는 케이스가 꽤 있습니다. 그 루트도 굉장히 상식의 범위를 넘어다니는데 이슈를 엉뚱한 곳에서 크게 키운 다음 그 이슈 관련해서 납품처의 인맥을 타고 내려오거나 현재 회사의 사장이나 기타 인맥을 타고 내려오거나 등등 다양합니다.

사용할 수 없는 이유를 논리적으로 거절해야 하기 때문에 골치가 좀 아픕니다.

객관적인 테스트 비교 자료를 제공하거나 성능 시험을 보여줘서 처참하게 발라버려야 하는 경우도 있습니다.

일말의 여지도 주지 않고 말이죠

아니 개발 초기에 껴들면 그러려니 하는데 어느정도 다 되가고 뭔가 될 것 같으니까 마지막에 수저 얹으려고 하는 드러운 놈들이 좀 껴서 치워내느라 짜증이 날 수도 있습니다.

물론 윗선에서 잘 처리한다면 아주 좋겠지만 말이죠

 

10. 양산 시작~!! 그리고 안정화 성공!!

고생 많으셨습니다

회사측으로부터 그간 고생한 것에 대한 보상을 두둑히 받았으면 좋겠습니다.

그런데 끝이 아니죠

다음 모델에 대해 준비하고 개발 진행 생각하셔야죠 :)

다음 모델은 다른 회사와 경쟁을 할 수도 있습니다. 이 부분은 오해의 소지가 있는데 요즘은 원래 공급처 다원화를 위해 차량뿐만이 아니라 다 그런식으로 진행이 됩니다.

그래도 이미 노하우가 어느정도 잡혀있으니 경쟁사보다 더 잘 해낼 수 있으리라 봅니다~