로봇 액추에이터 펌웨어 설계

• 펌웨어의 전형적 구조를 알았으니, 이제 실제 설계 절차를 다룸 — 요구사항에서 출발해 태스크·주기·우선순위를 정하고, 상태 머신·보호 기능·통신 인터페이스를 설계
• 출제 포인트: 설계 절차의 순서, 주기가 짧을수록 우선순위를 높게 주는 원칙(Rate Monotonic), 페일세이프 설계(통신 두절·센서 이상 대응), 상태 천이 규칙, 이산화 구현 시 유의점

펌웨어 설계 절차 — 요구사항에서 검증까지

1. 요구사항 분석: 제어 성능(주기·대역폭·정밀도), 통신(프로토콜·주기), 보호·안전 기능, 환경 조건을 수치로 정의
2. 하드웨어 자원 검토: 요구를 감당할 MCU 선정 — 연산 능력(FPU 유무), 타이머/PWM·ADC 채널, 통신 컨트롤러, 메모리 용량
3. 아키텍처 설계: 실행 구조 선택(전경/배경 vs RTOS), 태스크 분할과 주기·우선순위 결정, 계층 구조·모듈 경계 정의
4. 상세 설계: 각 모듈의 인터페이스, 상태 머신, 통신 프레임, 파라미터 맵, 보호 로직의 임계값·반응 정의
5. 구현과 검증: 코딩 규칙(예: 안전 지향 C 코딩 표준인 MISRA C)을 지켜 구현하고, 단위시험 → 통합시험 → 성능시험으로 검증

이 흐름은 요구사항→설계→구현→시험이 대응 관계를 이루는 V-모델 개발 절차의 축소판이다 (일반론: 로봇 시스템 평가절차).

태스크 설계 — 주기, 우선순위, CPU 여유

아키텍처 설계의 핵심은 "어떤 일을, 얼마나 자주, 얼마나 급하게"의 결정이다.

• 태스크 도출: 전류/속도/위치 루프, 통신 송수신, 보호 감시, 상태 관리, 로깅 등으로 분할
• 주기 결정: 제어 이론이 요구하는 주기(안쪽 루프일수록 짧게)를 하드웨어 능력과 절충
• 우선순위 부여 — Rate Monotonic 원칙: 선점형 스케줄링에서는 주기가 짧은 태스크일수록 높은 우선순위를 준다. 직관적으로도, 자주 와야 하는 일이 오래 기다릴 수 없다
• CPU 사용률 여유: 모든 태스크의 (실행시간 ÷ 주기) 합, 즉 CPU 사용률이 한계에 붙으면 데드라인 미스가 난다. WCET 기준으로 계산하고 여유(통상 30% 이상)를 남긴다

상태 머신 설계 — 허용되는 동작을 구조로 강제한다

상태(State)와 천이(Transition) 조건을 명시적으로 설계한다. 전형적인 예:

• 초기화(Init): 자기 진단(메모리·센서·전원 체크), 파라미터 로드 → 이상 없으면 대기로
• 대기(Standby, 서보 OFF): 전력단 차단 상태로 명령 대기 → "서보 ON" 명령으로 운전으로
• 운전(Run, 서보 ON): 지령 추종. 이 상태에서만 토크 출력 허용
• 오류(Fault): 보호 조건 발생 시 어느 상태에서든 진입 — 전력단을 즉시 안전 상태로 하고 오류 코드 기록. 원인 해소 + 명시적 리셋 명령이 있어야만 벗어난다 (자동 재기동 금지가 원칙)

상태 머신으로 설계하면 "대기 상태에서 토크 지령이 와도 무시한다" 같은 안전 규칙이 코드 구조 자체로 보장된다.

보호·안전 기능 설계 (실무·시험 모두 중요)

액추에이터 펌웨어에는 반드시 보호 계층이 들어간다.

통신 인터페이스 설계

상위 제어기와의 연결 규약을 정의한다 (프로토콜 일반론: 로봇 구성 요소 간 통신 프로토콜, 설계 방법: 통신 프로토콜 설계).

• 물리 계층 선택: 노이즈에 강하고 멀티드롭이 되는 CAN이 모터 제어기의 사실상 표준(CANopen 프로파일). 그 외 RS-485, 고성능 다축 동기에는 EtherCAT 등 산업용 이더넷
• 프레임 설계: 주기 메시지(지령·상태 — 위치/속도/토크, 상태 워드)와 비주기 메시지(파라미터 읽기/쓰기, 오류 조회)를 구분
• 건전성 장치: 체크섬/CRC, 시퀀스 카운터, 수신 타임아웃(→ 페일세이프 연계)

수치 구현 시 유의점

• 이산화: 연속 시간 PID를 샘플링 주기 T_s의 차분식으로 변환해 구현한다 (이산 PID). 주기가 일정해야(지터 최소) 계수가 유효하다
• 고정소수점 스케일링: FPU가 없으면 물리량을 정수로 스케일링 — 오버플로와 분해능 손실을 항상 점검
• 단위 일관성: 통신은 펄스·정수 단위, 제어는 SI 단위인 경우가 많아 변환 계수를 한곳에서 관리한다
• 파라미터 관리: 게인·리미트를 코드에 박지 않고 파라미터 영역에 두어 재빌드 없이 조정 (체크섬으로 보호)

상태 머신 설계 예

stateDiagram-v2
    [*] --> Init
    Init --> Standby : 자기 진단 통과
    Init --> Fault : 진단 실패
    Standby --> Run : 서보 ON 명령
    Run --> Standby : 서보 OFF 명령
    Run --> Fault : 보호 조건 발생
(과전류·과열·통신 두절 등)
    Standby --> Fault : 보호 조건 발생
    Fault --> Standby : 원인 해소 + 리셋 명령

펌웨어 설계 절차

flowchart TD
    A["① 요구사항 분석
성능·통신·안전 수치화"] --> B["② 하드웨어 자원 검토
MCU·주변장치 선정"]
    B --> C["③ 아키텍처 설계
실행 구조·태스크 주기·우선순위"]
    C --> D["④ 상세 설계
상태 머신·프레임·보호 임계값"]
    D --> E["⑤ 구현 (코딩 표준 준수)"]
    E --> F["⑥ 검증
단위 → 통합 → 성능시험"]
    F -. "미달 시 재설계" .-> C

CPU 사용률

예: 전류 ISR 20 µs/50 µs 주기(40%) + 속도 50 µs/500 µs(10%) + 위치 100 µs/1 ms(10%) + 통신 등 10% → 약 70%.

1. 액추에이터 펌웨어 설계 절차를 순서대로 옳게 나열한 것은?

① 상세 설계 → 요구사항 분석 → 구현 → 아키텍처 설계 ② 요구사항 분석 → 하드웨어 자원 검토 → 아키텍처 설계 → 상세 설계 → 구현·검증 ③ 구현 → 요구사항 분석 → 시험 → 설계 ④ 하드웨어 자원 검토 → 구현 → 요구사항 분석 → 검증

2. 선점형 스케줄링에서 Rate Monotonic 원칙에 따른 우선순위 배정으로 옳은 것은?

① 실행 시간이 긴 태스크에 높은 우선순위를 준다 ② 주기가 짧은 태스크에 높은 우선순위를 준다 ③ 나중에 생성된 태스크에 높은 우선순위를 준다 ④ 통신 태스크에 항상 최고 우선순위를 준다

3. 상위 제어기와의 통신이 일정 시간 두절되었을 때 액추에이터 펌웨어의 대응으로 가장 적절한 것은?

① 마지막으로 수신한 속도 지령을 계속 유지한다 ② 통신이 복구될 때까지 최대 속도로 원점에 복귀한다 ③ 수신 타임아웃을 감지해 감속 정지 등 미리 정의된 안전 동작으로 전환한다 ④ 아무 조치 없이 재부팅을 반복한다

4. Fault(오류) 상태의 설계 원칙으로 옳지 않은 것은?

① 어느 상태에서든 보호 조건이 발생하면 진입할 수 있어야 한다 ② 진입 즉시 전력단을 안전한 상태로 만든다 ③ 발생 원인을 오류 코드로 기록한다 ④ 원인이 남아 있어도 일정 시간이 지나면 자동으로 운전 상태로 복귀한다

5. 다음 중 감지 즉시 PWM 출력을 차단해야 하는, 가장 긴급한 보호 항목은?

① 온도의 완만한 상승 ② 과전류 ③ 통신 프레임 체크섬 오류 1회 ④ 로그 버퍼 가득 참

• 로봇 액추에이터 펌웨어 구조 — 설계의 재료가 되는 구조 유형·계층
• 임베디드 프로그래밍 특성 — WCET·인터럽트 등 설계의 전제 지식
• 제어기 소프트웨어 성능시험 — 설계·구현 결과의 검증
• 로봇 구성 요소 간 통신 프로토콜 — CAN 등 통신 버스 일반론
• 통신 프로토콜 설계 — 프레임·프로토콜 설계 방법
• _MOC 모션소프트웨어