|
|
|
|
|
 |
통신 장애가 간헐적으로 발생할 때, 로깅과 계측을 어떤 기준으로 설계하십니까
예를 들어 다음과 같은 방식입니다.
제품의 신뢰를 코드로 구현하고, 그 신뢰가 현장에서 반복되게 만드는 사람이 되고 싶기 때문입니다.
안정성은 기능보다 먼저 설계돼야 한다는 점입니다.
원인 규명 중심의 문제 해결입니다.
시스템 관점입니다.
펌웨어 개발은 단순히 버그를 없애는 일이 아니라, 장애가 있어 도 시스템이 버티게 만드는 설계를 하는 일입니다.
부팅 신뢰입니다.
|
|
|
 |
FWE ngineer로서 디바이스 부팅부터 기능 동작까지 전체 흐름을 어떻게 설계하고 검증하십니까
제가 FWE ngineer를 선택한 이유는 단순합니다.
시스템이 현실에서 움직이는 지점은 결국 펌웨어이고, 그펌웨어는 "작동한다"와 "현장에서 믿고 쓴다" 사이에 огром 한 간극이 존재한다는 것을 경험으로 알았기 때문입니다.
제가 펌웨어를 진지하게 공부하게 된 계기는, 학교 프로젝트에서 센서 데이터 수집 장치를 만들면서 겪은 실패였습니다.
C 언어를 단순 문법이 아니라 메모리 모델 관점에서 다시 공부했고, 포인터, 정렬, volatile, ISR과 메인 루프간 공유데이터, 원자성 같은 주제를 실제 코드로 실험했습니다.
UARTI2CSP I 같은 통신을 단순히 데이터가 오가면 끝이라고 보지 않고, 타이밍, 오류 프레임, 재시도 정책, CRC 같은 안정성 요소를 함께 설계하는 연습을 했습니다.
펌웨어는 사용자가 직접 만지는 UI가 아닐 수도 있지만, 사용자가 체감하는 응답 속도와 안정성, 오류 메시지의 의미를 사실상 결정합니다.
저는 이런 제품 관점의 판단을 습관으로 만들고 싶어서, 기능 요구사항을 읽을 때도 반드시 사용 시나리오를 먼저 그립니다.
저는 펌웨어가 "하드웨어 위에 얹힌 코드"가 아니라"신뢰를 구현하는 레이어"라는 관점으로 일을 하고 싶습니다.
제품의 신뢰를 코드로 구현하고, 그 신뢰가 현장에서 반복되게 만드는 사람이 되고 싶기 때문입니다.
제가 가장 열정을 가지고 임했던 프로젝트는 임베디드 디바이스에서 실시간 이벤트를 처리하고, 통신장애가 있어 도 시스템이 멈추지 않도록 만드는 펌웨어 개선 과제였습니다.
제가 이 프로젝트에 몰입했던 이유는 단순히 버그를 잡는 것이 아니라, "왜 멈추는지 모르겠다"는 상태를 "원인을 설명할 수 있다"로 바꾸는 과정이었기 때문입니다.
수정 후에도 저는 바로 성공이라고 결론 내리지 않았습니다.
문제를 고치고 나면 다른 문제가 생기는 것이 임베디드의 현실이기 때문에, 최소 테스트 세트를 만들어 반복 실행했습니다.
안정성은 기능보다 먼저 설계돼야 한다는 점입니다.
원인 규명 중심의 문제 해결입니다.
저는 문제가 생기면 바로 수정부터 하지 않습니다.
특히 펌웨어 영역에서는 "고친 것 같은데다시 터지는 "문제가 가장 비싼 문제입니다.
약점은 완벽주의 성향이 과해지면 속도가 느려질 수 있다는 점입니다.
저는 장애가 발생해도 자동복구가 동작하도록 만들고, 복구 실패시에는 사용자에게 명확한 상태를 제공하도록 했습니다.
또한 로그는 단계 전이와 실패 원인을 숫자로 남겨, 현장에서 부팅 실패가 발생해도 원인을 추정할 수 있게 설계합니다.
답변 : 실시간 성 이슈는 대부분 우선순위와 블로킹, 그리고 공유 자원에서 발생합니다.
저는 먼저 증상을 수치로 만들기 위해 tas k별 실행 시간, 주기, 지연시간을 계측하고, 어떤 task가 데드라인을 놓치는지 확인합니다.
높은 우선순위task가 긴 시간 CPU를 점유하거나, 낮은 우선순위task가락을 잡고 있어 우선순위 역전이 발생하는지 확인합니다.
또한 문제가 발생하는 시점의 직전 상태를 확보하기 위해 링버퍼에 핵심 상태전이와 메모리 지표를 저장해 두고, 장애감지 시 덤프하도록 설계합니다.
답변 : 펌웨어 보안은 한 가지 기술로 해결되지 않기 때문에 계층으로 설계해야 한다고 봅니다.
업데이트 신뢰입니다.
디버그 인터페이스 관리, 민감정보의 저장방식, 키 관리와 접근제어, 오류 발생 시 정보 노출 최소화가 필요합니다.
로그에 민감정보가 노출되지 않도록 기준을 만들고, 현장 진단 기능과 보안요구가 충돌할 때 의 원칙을 세웁니다.
그래서 문제 상황이 발생하면 먼저 재현 조건, 발생 빈도, 영향 범위를 문서로 정리하고, 로그와 파형, 계측 데이터처럼 객관자료를 확보합니다. |
 |
통신, 만들다, 상태, 발생, 이다, 문제, 펌웨어, 장애, 기능, 설계, 어떻다, 코드, 성, 현장, 조건, 안정, 해결, 원인, 버퍼, 부팅 |
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
2025.12.22
9페이지
