[현대오토에버 모빌리티 SW스쿨] 8주간의 임베디드 프로젝트 회고

1차 프로젝트 : 차량 설정 개인화

사용자에 따라 핸들의 높이와 위치, 시트 위치, 주행 보조 기능의 설정, 편의기능의 설정 등이 달라집니다.
이러한 부분을 자동차 스마트키나 핸드폰을 통해 사용자를 식별해 다르게 적용하면 좋겠다!!

https://github.com/2MoPLZ/TunnelMate

GitHub - 2MoPLZ/TunnelMate

개요

• 과제 : 차량의 모듈(시스템) 중 일부를 소규모로 임베디드 보드를 활용해 직접 구현
• 기간 : 2주 + 연휴
• 주제 : 개인과 상황에 맞는 차량 자동 설정
  • 스마트폰 블루투스를 차량에 연결하면, DB에서 사용자별 설정을 불러와 차량에 적용한다.
    (창문, 시트, 에어컨, 전방 충돌 방지 보조 알림, 내부조명 등)
  • 사용자가 설정을 변경하면 그 변경된 설정이 DB에 적용된다
  • 주행 모드나 상황(터널, 빗길) 에 맞는 사용자별 사전 설정이 존재하고, 센서를 통해 그러한 상황을 인식해 설정을 적용한다
• 상세 : 
  • 3개 임베디드 보드를 이용해 자동차의 Zonal Architecture를 간단히 모방
  • ESP32를 사용해 핸드폰과 블루투스 통신, 서버(데이터베이스) 와 와이파이 통신
  • 1개 STM보드를 사용해 메인 게이트웨이 및 HPC 구성
  • 1개 Tricore 보드를 사용해 대시보드 및 조작버튼, 초음파센서, 조도센서를 포함한 센서-대시보드 ZCU구성
  • 1개 STM보드를 사용해 서보모터, LED, 팬, 부저 등 다양한 액추에이터들을 포함한 액추에이터 ZCU 구성
  • 보드 간 통신을 위해 자체적으로 설계한 패킷과 프로토콜 사용, UART 통신 
• 내 역할 :
  • Tricore 보드에서의 erika3 RTOS를 사용한 TASK 및 주기 설계, 구현
  • 초음파센서 라이브러리
  • Tricore 보드용 UART 송/수신
  • Tricore 코드 통합 및 테스트
  • 영상편집
  • 문서화 : https://github.com/2MoPLZ/TunnelMate/tree/develop/TC275 및 엑셀 시트

그렇지만 개인적인 만족도 45점
 -  꼭 구현해야 할 부분들은 다 구현했고 시연도 성공적으로 됐는데, 발표가 너무 망했고, 기간 중 답답한 부분도 많았다

 

왜 망했을까?? :

• 확정사항이 제대로 관리되지 않음, 개발 초기 주제 불명확 -> 팀원들 간 이해 불일치
• A-SPICE를 이론적으로만 배웠지 실제 프로젝트에 적용하기는 처음이기 때문에 요구사항 단계에서 시간을 과하게 소모함
• A-SPICE 관련 양식도 전달받은 게 없고 팀원들 간 이해의 불일치 때문에 문서 양식과 세부적인 표현들이 통합되지 않음
• 시스템 통합 단계에서의 어려움 - 배선은 점점 복잡해지는데 어떤 문제가 하드웨어 이상인지 소프트웨어 이상인지 알기 어려움
• 시스템 통합 단계에서 되던 통신이 갑자기 안 됨 - 원인을 찾기 어렵고 테스트도 복잡해짐
• Git 과 JIRA에 익숙하지 않아 사용이 미숙하고 소극적이여서 안되는 소통이 더 안됨
• 통합 단계에서 시간을 너무 많이 소모해서 발표자료 준비할 시간 부족, 야근하다 보니 발표자료를 준비할 에너지가 없음
• 영상이랑 발표자료에 대한 팀원들 간 피드백이 제대로 안 됐음
• 일단 통합이 되면 코드를 건드리기가 무서워지는 분위기 -> 리팩토링 불가능

 

발표 이후 교수님에게도 발표가 너무 망했고 영상에서도 뭘 보여주려는지 모르겠다는 평가를 받았다

 

이외에도 프로젝트를 망친 원인들을 개인적으로 분석하고 장문의 회고록을 작성해 팀원들에게 공유했다.

내용이 진짜진짜 길다

https://www.notion.so/1-22ce4f34d8d280c8a801da319a0dfcdf?source=copy_link

미친짱긴1차회고록 | Notion

 

결국 핵심적인 내용은

• R&R을 확실히 하고 PM은 강력한 권한을 갖는 대신 감독을 확실하게 해라. 개발 일선에서 물러나 상세한 지시를 해 줘라
• A-SPICE 단계별로 확실한 목표를 잡아놓고, 최소한 그 목표를 달성하기 전까지는 다음 단계로 넘어가지 말자
• 자기 업무에 대한 데드라인을 잘 지키고 진행도를 팀원들에게 공유하자. 그걸 위해 협업 사이트를 잘 활용하자
• 발표준비 미리 잘 하자. 발표를 위한 자료들을 개발하면서 미리 남겨놓자

이 회고록을 팀원들에게 배포한 뒤 1시간동안 팀원들끼리 모여서 회고를 진행하고 합의점을 찾아 다음 프로젝트를 진행했는데

과연 다음 프로젝트와 다다음 프로젝트에서는 이러한 것들이 잘 지켜졌을까?

---

2차 프로젝트 : 차량 자동 선적 시스템

자동차가 공장에서 나온 후 선적지까지 옮기고 배에 싣는 과정에 비용이 발생합니다
이러한 부분을 해결하기 위해서, 선적지까지 차량을 옮기는 과정에 자율주행이나 플래투닝이 활용되고 있는데
자동차 운반선에 특화된 정밀 주차 제어 시스템은 아직까지 없습니다. 이것을 제어 시스템과 2대의 RC카로 구현해 봅니다.

 

https://github.com/2MoPLZ/ShiParker

GitHub - 2MoPLZ/ShiParker

 

개요

• 과제 : 자율주행 프로젝트. 어쨌든 굴러가는 자동차
• 기간 : 2주
• 주제 : 차량 자동 선적 시스템
  • 제어 시스템과 차량들로 구성
  • 주차장의 구조는 이미 다 알고 있다고 가정(주차 가능한 고정된 위치가 있고 제어 시스템이 그곳에 주차하라고 명령)
  • 차량 선적의 특수성에 맞게 좁은 간격으로 정밀 주차하면서 빨리빨리 진행, 절대 사고나지 않도록 진행
  • 주차 중 일시정지, 중단, 재개 가능. 카메라를 이용해 주차되고 있는 상황을 모니터링 가능

• 상세 : 
  
  • PID 제어를 사용해 한쪽 벽을 따라가는 알고리즘 구현
  • 1개 Tricore 보드의 싱글코어 사용, RTOS 사용.
  • 엔코더모터와 초음파센서를 이용해 주차장 내에서의 차량 위치 파악, 정밀 주차
  • 최최최최소한의 기능안전 반영, 기능안전 요구사항을 도출을 위한 HARA, KANO, ASIL
  • 파이썬을 이용해 주차 제어 시스템 UI구현
  • 라즈베리파이 보드를 MQTT 브로커로 사용, ESP32와 라즈베리파이 보드 간 MQTT 통신
  •  
  • 말이 자율주행이지 키트가 너무 열악해서 자율주행 관련 부분은 거의 하드코딩에 가까움
  • dc모터와 홀센서(+바퀴당 6개 자석)을 이용해 급조한 엔코더 모터의 성능과, 싱글코어 RTOS에 다양한 기능을 담다 보니 센서의 안전한 측정 주기를 확보하지 못한 문제로 인해 주차 정밀도가 끔찍함
• 내 역할 :
  • Tricore 보드에서의 erika3 RTOS를 사용한 TASK 및 주기 설계, 구현
  • 자율주행 자동차 메인 로직 - state machine 설계 및 구현
  • 개선된 초음파센서 라이브러리
  • UART 패킷 설계, MQTT 브로커 설계
  • UART 송/수신
  • Tricore 코드 통합 및 테스트
  • 영상편집
  • 문서화
  • Confluence를 이용한 일일 업무일지 및 회의록 작성 및 확정사항 정리 를 정말 열심히 했는데 아무도 안봐👺👺👺

개인적인 만족도 41.5점

 

왜 망했을까?? :

• A-SPICE를 준수하는 방법에 대한 확신이 여전히 부족한 상태
• 가장 큰 원인 : 너무 열악한 RC카 키트
  • DC모터의 토크가 약함 - 제어값이 같아도 다르게 동작하며, 건전지가 조금이라도 모자라면 이상하게 동작함 -> 건전지를 왕창 사용하게 됨
  • RC카 키트와 호환되는 엔코더 모터는 국내에 재고가 없어서 배송되려면 2주가 걸림
  • DC모터와 홀센서와 자석을 이용해 급조한 엔코더 모터는 정확도가 떨어져서, 바퀴 1회전 당 찍히는 인터럽트 횟수가 다름
  • 제공된 RC카 키트의 바퀴 지름도 조금씩 다름
  • 초음파센서를 이용할 때 측정면 상태에 따라 튀는 값이 발생하는 문제
  • 초음파센서 간 간섭을 의식해 폴링 방식으로 구현 -> 과도한 자원 소모
• 모터 제어 라이브러리 개발이 늦어지고 클래스다이어그램이나 함수 입/출력 설계 및 테스트 스텁을 제공받지 못함. 이로 인해 모든 단계의 통합이 늦어짐
• JIRA 담당자의 면접 이슈로 인해 JIRA가 방치됨
• 주차 과정 병렬화를 위한 노력 -> 실패
• 일단 통합이 되면 코드를 건드리기가 무서워지는 분위기 -> 리팩토링 불가능한데도 몰래몰래 조금씩 하긴 했다
• RTOS 설계상의 실수 - 코드의 복잡도 증가, 자원 사용 증가, 설계의 무결성을 입증하기 어려움
  • 여러개의 알람 각각에 TASK를 매칭시켰는데 이로 인한 자원 소모가 큰 것으로 예상됨 - 한개의 알람과 여러개의 플래그를 사용해 여러가지 TASK를 관리했다면 나았을 것
  • 멀티코어를 어떻게든 사용해볼걸 하는 아쉬움이 남음
• 패킷 설계상의 사소한 실수, 시스템 설계상의 사소한 실수
• 안 그래도 늦게 시작된 통합 단계에서 많은 문제 발생
  • 라즈베리파이를 MQTT브로커로 사용하면서 UI도 띄우고 카메라도 쓰려다 보니 라즈베리파이가 뻗음 -> OS부터 새로 세팅
  • TASK 터짐 -> 정확한 문제가 뭔지도 모르겠음 -> 우선순위와 주기를 조금씩 수정하면서 최적값을 찾는데, 컴파일러는 또 너무 느리고 코드 복잡도는 이미 크게 증가한 상태
  • 하드웨어 배선 문제(항상 공통 그라운드를 잘 맞춰주자)
  • 제공 실습품에 ESP32가 포함되어 있지 않아서 집에서 가져온 걸 사용했는데, 2개 ESP32 모델이 달라서 뭐가 문제인지 판단하기도 어렵고 코드를 조금 수정하기도 어려움
• 통합이 크게 꼬여서 영상과 발표자료를 급조 - 최종 제출물과 영상의 구현된 정도가 다름 -> 시연장에 없었던 교수님들의 평가에 큰 영향을 미쳤을 것으로 예상

 

이 프로젝트를 진행하면서는 주최측에 아쉬운 부분이 많았다

자율주행 프로젝트라기엔 키트가 너무 열악했고

기계과 교수님들이 많이 와서 알려주시고 평가에 참여했는데, 교육과정 중 Simulink를 다루지 않아서 활용에 제약이 많았고 (우리 조는 결국 안 썼지만 다른 조들은 어떻게든 활용하더라) 결과적으로도 제어 쪽 설계가 우수한 팀이 상을 가져갔다

1차 프로젝트가 끝나자마자 2차 프로젝트를 바로 시작했기 때문에 힘들기도 하고, 1차 프로젝트에서 어떤 부분을 고쳐야 하는지도 모른 채 시작했다

 

---

3차 프로젝트 : 차세대 차량 소프트웨어 업데이트 및 진단 프로세스

-> 최우수 프로젝트상 수상

SDV 시대에 차량 산업은 하드웨어 중심에서 소프트웨어 중심으로 변화합니다. 이에 따라 차량에는 보다 편리하고 안전한 소프트웨어 업데이트 프로세스가 요구되고, 서비스 기반 통합 진단을 필요로 합니다
Vehicle update manager 와 Vehicle data collector 라는 별도 모듈을 설계하고, 차세대 소프트웨어 업데이트 프로세스와 진단 프로세스를 정의합니다. 그것을 VECTOR CANoe와 DYNA4 를 이용해 시뮬레이션합니다.
거기에 CI/CD/CT 컨셉을 곁들인

CANoe내에서 작업해서 깃허브는 따로 없음. 발표자료는 RAPA DX스쿨 홈페이지에 게시될 예정

개요

• 과제 : VECTOR CANoe를 이용한 차량용 통신 프로젝트
• 기간 : 4주
• 주제 : 차세대 차량 소프트웨어 업데이트 및 진단 프로세스

• 상세 : 
  
  • A-SPICE, CI/CD/CT, 기능안전, 사이버보안 향 첨가
  • 현직자 평가가 중요하다고 판단해, 최대한 표준과 실제 작업물을 따라가려는 노력
  • 많은 자료 참고
    
    • 현대자동차 정비매뉴얼
    • 제네시스 CANdb
    • AUTOSAR UCM
    • ISO26262
    • ISO21434
    • ISO14229
    • KISA 자율주행차 보안모델 中 SUMS부분
• 내 역할 :
  • 소프트웨어 업데이트 관련 자료조사, 업데이트 프로세스 설계
  • ISO-TP (진단 서비스의 멀티프레임 전송을 위한 캡슐화,역캡슐화 및 플로우 컨트롤) 구현
  • VUM(업데이트 매니저) 설계 및 구현
  • 산출물, 문서화
  • 영상편집

개인적인 만족도 55점

 

상을 왜 탔을까?? :

• 8주동안 구르면서 영상편집 스킬이 늘어서
• 최신 트렌드 향 첨가를 적절히 해서
• 소프트웨어 업데이트 및 진단 표준을 준수하려는 노력이 발표자료에 잘 들어감
• 이번엔 양식을 주최측에서 어느 정도 제공해줬고 그걸 기반으로 산출물을 고봉밥으로 뽑음

 

상탔는데 왜 또 만족을 못했을까?? :

• 가장 큰 원인 : 익숙하지 않은 CAPL로 구현하며 기획한 부분 중 많은 부분을 생략하게 되었다
• 표준문서를 많이 참고해서 뭘 해야되는지는 확실하게 아는데, 못 한 부분이 너무 많다
• 지쳐가지고......... 워라밸 확실하게 지키면서 일했고 최선을 다하지 못했다고 생각한다
• CANoe가 정말 좋은 프로그램은 맞는데 다중 사용자의 동시 작업이 어렵기 때문에 협업이 제대로 이루어지지 못했다고 생각
• 주제 선정과 구체화에 과하게 많은 시간이 소요됨
• 패널 설계가 약간 조잡함
• CAPL에 익숙하지 않아서 코드 구조가 맘에 안든다

---

 

총평

1. 프로세스대로 개발하기는 정말 어렵지만 무결한 설계와 구체적인 산출물이 추후 생기는 문제들을 많이 예방해 준다는 건 확실히 알았다. A-SPICE를 잘 지키자
2. 8주동안 3개 프로젝트를 연속으로 시킨 건 너무한 것 같다
3. 임베디드 프로젝트에서 하드웨어로 인한 제약이 크다. 미래시를 갖고 미리 준비했다면 좋았을걸 + 주최측에서 미리 좀 알려주지 + 일단 배송하고 볼걸 이라는 생각이 든다
4. 툴 사용이 정말 중요하다.
   1. AI 어시스턴트 -> 논란이 있을 수 있는 부분이다. 맹신하면 안되지만 사람의 피드백을 기다리는것보단 20000000배 빨리 피드백이 도착하니까 AI의 도움을 받는 게 개발 프로세스의 한 부분이 되지 않을까 싶기도 하다. 대신 그 결과는 사용자의 몫
   2. RTOS 설계 검증 -> 2차 프로젝트에서 TASK 왜 터졌는지 정확한 이유를 아직도 모르겠다!!! RTOS에 대한 검증 일이 NP-HARD 라고 들었는데 이런 건 툴을 쓰거나 확실한 시뮬레이션을 거치는 게 맞다. 내 머리론 답이 안나오는 일이다
   3. 문서, 테스트 자동화 -> 엑셀로 문서 뒤지면서 추적성 만들고 테스트케이스 하나하나 작성하는건 정말 재미없는 일이다
   4. CI/CD/CT -> 통합을 프로젝트 막바지에 시작하면 어떤 일이 일어나는지 1,2차 프로젝트에서 아주 잘 느꼈기 때문에 지속적인 통합이 얼마나 좋은 방법인지 알겠다...
5. 어쨌든 좋은 기회를 통해 정말 많은 것들을 배워가는 기회가 되었다