기본 콘텐츠로 건너뛰기

ECU가 급발진을 하는 근본적인 원인에 대해 제어계측 전공자가 분석해 봄(개인 의견)


ECU가 급발진을 하는 근본적인 원인 분석




여기서 하는 이야기는 순전히 회로기판 설계에 대한 지식이 있는 공학도로서의 개인적인 의견이므로 100%맞는다고 보장하지 않지만, 최대한 근거 있는 이야기를 드리려고 합니다. 

제어계측 출신으로서 급발진 사고의 대응이 안된다는 것은 좀 말이 안된다는게 제 생각입니다. 

지금도 KDDI 본사 등 RPA 교육도 하기도 하면서 workflow automation쪽도 많이 보고 있는데요.. 

뭐.. 관계가 없다고 보시는 분들도 계시겠지만, 모든 것은 workflow분석 및 unintended accident에 대한 대처는 기본이지 않나요? 

그리고 기사들을 보니까 일반인들을 속이기 딱 좋게 편집이 되어 있는게 느껴지는데요.. 

외국차도 UA가 있더라.. 요 단어는 뒤에 accident가 아니고 acceleration입니다. . 

그러면서 BMW를 보여주는 영상이 있어서 봤는데 마지막으로 점검 한게 사제 정비소에서 ECU펌웨어 업그레이드 했다고 하더군요... 대부분 공식은 실제로 업그레이드지만, 사제 정비소는 ECU튜닝이라고 해서 업그레이드가 아닌 자기네가 손댄 튜닝 룰에 의한 프로그램 조작 입니다. .. 뭐 수치 정도만 조작 했겠지만.. 
문제는 튜닝은 최신 펌웨어를 쓰는 것보다 기존의 펌웨어에 튜닝된 수치를 넣은 파일을 넣는 경우가 대부분 이기 때문에 급발진 가능성이 있는 코드가 심어져 있을 떄 일거란 말이죠.. 

게다가 오래된 외제차들의 사고를 자꾸 보여주네요.. 
신형 외제차들 중에 만약 있다면 한국에 들여오면서 ECU를 손대지 않았나 의심을 해 봐야 합니다. 거의 그 원인일 겁니다. 




토요타조차 2005년을 마지막으로 급발진 사고가 없었습니다. (있었는데 감췄을... 지도;;)
아마 자기네 결함을 인지하고 방법을 강구 했겠죠.. 
그렇게 해서 나온게 ICS입니다. 




급발진이든 운전자 미숙이든 연료 공급을 차단하고 브레이크를 강제로 거는 기능이네요. 
토요타에서는 브레이크를 자동으로 걸어주는 기술이라고 적혀있지만, 
어떠한 급발진 사고도 쓰로틀이 전개 되어 있는 상태에서는 브레이크는 아무 도움이 안되는것을 알고 있겠지요? 
때문에 토요타는 공개는 안했지만 아마 연료 공급 차단장치를 추가 했을 겁니다. 

즉, 메인 ECU가 어떤 동작을 하든 전혀 다른 제어 장치가 메인 ECU의 제어를 무시하고 연료 공급을 닫아버리면 아무리 쓰로틀 밸브가 전개 된다고 엔진이 돌아가나요? 


토요타의 2005년 사고로 인한 분석 자료를 봤습니다. 
코드 자체의 문제도 있었으나, 
어플리케이션 이상 종료시 쓰로틀밸브 각도를 1.. 즉 완전 개방으로 하도록 되어 있다는게 검출 되었습니다. 
많은 원인도 있었지만, 가장 컸던 이유 같습니다. 

그리고 바보가 만들지 않는 이상 여러가지 코드로 예외 처리를 많이 해놓았을 것입니다. 

하지만 많은 개발자들이 간과했던게 있죠. 바로 자신의 코드의 문제 이전에 OS도 죽을 수 있다는 겁니다. 
어떠한 하드웨어든 펌웨어라는 소프트웨어와 디바이스를 연결해주는 자체 OS를 가지고 있습니다. 
그 펌웨어에 직접 연결하는 어플리케이션도 있으나, 좀더 개발을 쉽게 하기 위해서 Embeded Linux같은 OS를 추가로 올리는 경우도 있지요.. .. 가장 중요한 것은 어떠한 OS도 펌웨어도 오류가 나면 뻗을 수 있다는 것입니다. 
그 오류로 분명 쓰로틀밸브를 1로 한 채 멈췄겠지요.. 

또하나 간과하고 있는게.. 
회로 기판은 주변의 자기장과 전기장 영향을 많이 받습니다. 

왜 옛날에는 IBM에서 만든 피씨는 안정적이었는데 중국산 이름모를 피씨는 자꾸 오류가 떴을까요?

우리때는 OrCAD로 회로 기판을 설계했는데.... 

저렴한 회로 기판과 비싼 회로 기판은 똑같이 보드로 찍어내도 겉으로는 오류가 보이지 않습니다. 
그럼 저렴한거 써야지요? 

바로 거기가 경험의 차이입니다. 

제가 OrCAD로 설계한 회로 기판을 
그냥 빵판에서 선을 연결해서 만들었던 적이 있는데.. 
NAND회로도 제대로 설계했는데 1+1을 보냈는데 10이 안되고 01이 되는 현상이 있었습니다. 

왜 안되지 하고 오실로스코프를 보면서 납땜이 잘못 되었나 하고 조심스레 선을 하나씩 옆으로 치우면서 보는데 갑자기 10으로 바뀌는걸 확인 했던 적이 있지요. 

우리가 고등학교때 배웠던 플레밍의 오른손 법칙 있잖아요.. 

그게 바로 선 위를 흐르는 전류 때문에 발생하는 전기장의 영향으로 미세하게 전류의 흐름이 늦어지거나 하면 연산 오류가 나는 것입니다. 

특히나 요즘처럼 7중 이상으로 빵판을 만드는 경우 아주 작은 외부 영향으로도 전자의 흐름에 영향을 받아 연산 오류가 날 수도 있지요. 하물며 고온엔진 근처에서 정전기 등등의 다양한 외압을 받고 있는 자동차는 더욱 심하지 않을까요? 
그런 외부 영향을 막겠다고 많은 처리를 했겠지만, 인간이 만든 이상 이게 100%라고 볼 순 없겠지요.. 

때문에 ECU의 동작 오류는 항상 생각해야 하는데, 
그걸 잘못을 인정한다느니 하는 이상한 선입관에 대응을 안한다는게 웃기더라구요.. 
H모사는 아마 지금도 개발자만 닥달해서 해결하라고 하고 있지 않을까요?

차라리 토요타처럼 ICS같은 멋드러진 이름으로 연료 차단장치 만들어 발표하면 더 이미지 좋아지지 않나요? 

이런 소리하면 또 이렇게 말하는 사람이 있겠지요.. 

그 ICS조차 망가지면 어떡하냐?

제가 인프라를 하잖아요? 

언제나 이중화를 설계해서 제공합니다. 그럼 고객이 얘기하지요.. 이중화 된 장비도 죽으면 어떡하냐?
이중화는 99.8% 가동율을 99.9999%로 늘릴 뿐입니다. 하지만 생각해보면 1년에 5번 오류 뜨는 것보다 10년에 1번 오류 뜬다면 저런 핑계를 대면서 1년에 5번 오류 뜨는거 쓰실 건가요? 

일본 트럭 중에는 속도 제한장치 장착 차량 이란게 있습니다. 


아무리 엑셀을 밟든 뭐하든 얼마든지 제어가 가능하다는 얘기지요. 

1분기 순익이 토요타랑 비슷해졌다고 기사를 내기 전에 
이 정도 조차 하지 않은 것에 부끄러워 해야 하지 않을까 싶다는 생각을 늘상 합니다.

요즘.. 일본에서조차 기사화 되고 있네요.. 


그냥 쓸데없이 찾아보다 나온 생각이었습니다. 










연간 급발진 사고 조사

「実は、米国では約20年前に、SUA(Sudden Unintended Acceleration=突然の予想外の加速)という単語が作られたほど、速度制御不能による事故が続いていました。特に1999年から2010年までの10年間でみると、トヨタ車だけで815事例、341重軽症、19死亡が報告されています。ドライバーの年齢層は30~40代がもっとも多く、『アイドル状態からの急加速』『ブレーキを踏んでいるのに加速が始まった』『高速道路を通常の運転中に加速した』など、さまざまな事故が発生していたのです」

トヨタ、プリウスなどに搭載の技術“ICS”により踏み間違い事故が激減!


giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...