🚚 WIA 배송 로봇 표준 전자책 | 제1장 (총 8장)

제1장: 라스트마일 배송 로봇과 WIA ROB-010의 자리

배송 로봇은 머릿속에 그리기는 쉽지만 시스템에 통합하기는 의외로 어렵다. 보도나 호텔 복도를 굴러가다가 정해진 사람 앞에서만 뚜껑을 여는 작은 바퀴 달린 상자—이것이 눈에 보이는 부분이다. 눈에 보이지 않는 부분은 데이터의 흐름이다. 로봇이 지금 어디에 있는지, 무엇을 싣고 있는지, 어떤 경로를 따르기로 했는지, 다음 작업을 맡겨도 안전한지를 플릿 플랫폼에 알려 주는 흐름이다. 제조사마다 이 흐름을 제각각 만들면, 두 회사의 로봇을 산 운영자는 플릿 플랫폼도 두 개를 운영하게 된다. WIA ROB-010은 바로 이 중복을 없애기 위해 존재한다.

이 장은 책 전체의 무대를 마련한다. 표준이 어떤 기계를 대상으로 하는지, 그 기계가 어떤 계층으로 구성되는지, 왜 상호운용성이 표준화할 가치가 있는 문제인지, WIA ROB-010의 네 단계가 어떻게 짜여 있는지, 인접한 ISO·OASIS·ROS 작업과는 어떤 관계인지, 규제 환경은 대략 어떤 모습인지를 설명한다. 마지막으로 이후 모든 장에서 공통으로 쓰는 표기 규칙과 예시 식별자를 정리한다.

1.0 시뮬레이터 지도: 다섯 패널과 여덟 장

이 표준에는 인터랙티브 시뮬레이터(delivery-robot 패키지의 simulator/index.html)가 함께 제공된다. 시뮬레이터는 참조 구현이 아니라 학습 보조 도구이지만, 이 책의 개념이 실제로 움직이는 모습을 가장 빨리 확인할 수 있는 수단이다. 화면은 다섯 개의 탭으로 이루어져 있고, 각 탭은 자바스크립트 함수 showPanel()로 전환된다. 표 1-1은 각 패널을 그 바탕 규칙을 설명하는 장과 연결한 것이다.

시뮬레이터는 시연용이므로 적합한 구현이라면 허용되지 않을 단순화를 곳곳에 두고 있다. 그중 세 가지는 지금 짚어 둘 만하다. 이 표준이 막으려는 바로 그 유형의 어긋남을 잘 보여 주기 때문이다.

• 식별자. 로봇 제어 패널에는 ROB-001-2025라는 로봇이 표시된다. 그러나 1단계는 robot_id를 UUID로 규정한다. 사람이 읽기 좋은 이름을 화면에 띄우는 것은 괜찮지만, 그것이 통신에 실리는 식별자가 되어서는 안 된다.
• 단위. 패널은 속도를 km/h로 보여 주고 최대 속도도 km/h로 입력받는다. 1단계에서 speed는 초당 미터(m/s)이며, 경로 제약 필드도 max_speed_ms이다. 대시보드가 표시용으로 환산하는 것은 자유지만 페이로드는 환산해서는 안 된다.
• 점검표 항목. 안전 패널에는 "GPS Accuracy: < 2m", "Weather Resistance: IP65" 같은 항목이 있다. 둘 다 네 개의 규범 단계 어디에도 없는 요구사항이다. 3단계의 목표는 GPS 단독이 아니라 센서 융합으로 달성하는 95백분위 위치 오차 0.5 m 미만이며, 방진·방수 등급에 대해서는 표준이 아무 말도 하지 않는다. 이 항목들은 시뮬레이터 제작자의 예시로 보아야 한다.

"화면이 보여 주는 것"과 "계약이 말하는 것"을 비교하는 일은 이 책 전반에서 되풀이된다. 이 차이를 알아보는 눈이야말로 통합 담당자가 가져갈 수 있는 가장 실용적인 기술 가운데 하나이다.

1.1 배송 로봇이란 무엇인가

WIA ROB-010에서 말하는 배송 로봇은 잠금과 접근 제어가 되는 밀폐형 적재함에 물건을 싣고, 배송의 마지막 구간을 저속으로 주행하는 바퀴형 자율 지상 이동체이다. 이 정의의 각 부분이 적용 범위를 좁힌다.

저속·바퀴형

대상 로봇은 대략 사람이 걷는 속도로 움직이며 보행자와 공간을 함께 쓴다. 보도, 횡단보도, 캠퍼스 산책로, 건물 로비, 복도, 엘리베이터가 그 공간이다. 표준은 속도를 하나의 숫자로 못 박지 않는다. 1단계는 로봇의 실제 속도를 speed(m/s)로, 경로 단위 제약을 max_speed_ms로 표현하고, 3단계는 혼잡한 곳에서 0.5 m/s로 감속하거나 차도를 1–2 m/s로 건너는 식의 행동을 규정한다. 저속이라는 특성의 귀결은 불확실할 때 멈추는 것이 대개 가장 안전한 반응이라는 점이며, 3단계에서 비상 정지와 "대기(WAITING)" 동작이 두드러지는 이유도 여기에 있다.

밀폐형 적재함과 접근 제어

택배 기사는 물건을 손에서 손으로 건네지만, 로봇은 누가 뚜껑을 열어도 되는지를 스스로 판단해야 한다. 그래서 1단계의 Package 모델에는 수령 코드, 선택적 QR 코드, 생체 인증이나 서명 확인 여부를 담는 access_control 객체가 들어 있다. 적재함이 하드웨어의 일부일 뿐 아니라 데이터 계약의 일부이기도 한 셈이다. 이는 보안 의무도 만든다. 수령 코드는 비밀 정보이므로 텔레메트리와 로그에 남아서는 안 되며, 이 점은 제3장에서 다시 다룬다.

라스트마일

라스트마일은 배송의 마지막 구간, 즉 지역 거점·매장·주방·보관함에서 수령인의 문 앞까지를 가리키는 물류 용어이다. 정차 지점이 가장 많고, 물량을 묶기 가장 어렵고, 지형이 가장 다양한 구간이어서 자동화의 관심이 쏠린다. 배송 로봇은 대체로 다음 세 환경 중 하나에서 이 구간을 맡는다.

• 실외 보도 배송 — 매장이나 소규모 거점에서 인근 주택·사무실까지.
• 캠퍼스 배송 — 대학, 병원, 산업단지, 주거 단지처럼 통로가 사유지이거나 반공공 공간인 곳.
• 실내 배송 — 호텔, 아파트, 사무용 건물, 병원 내부. 엘리베이터와 출입문을 거치는 경우가 많다.

표준은 이 셋을 별도의 로봇 등급으로 나누지 않는다. 같은 스키마를 쓰되 설정이 달라질 뿐이다. 예를 들어 경로의 주행 제약에서 sidewalk_only와 elevator_allowed 값이 달라지거나, 어떤 측위 원천이 주가 되는지가 달라진다.

배송 로봇이 아닌 것

배송 로봇과 한데 묶여 이야기되지만 WIA ROB-010의 범위 밖에 있는 인접 기술이 두 가지 있다. 표 1-2는 이들을 정성적으로 비교한 것이다.

이 비교가 중요한 까닭은 여러 설계 선택을 설명해 주기 때문이다. 드론 표준이라면 공역 조정이 필요하고, 도로 차량 표준이라면 고속의 차선 단위 교통을 다뤄야 한다. WIA ROB-010은 그 대신 보행자, 횡단보도, 사람과 물체 주변의 안전 여유 거리, 건물 기반 시설에 집중한다.

1.2 계층으로 본 시스템 구조

배송 로봇은 제조사와 관계없이 다섯 계층의 적층 구조로 설명할 수 있다. 이 구조를 이해해야 데이터 표준이 도울 수 있는 곳과 도울 수 없는 곳이 구분된다.

1. 하드웨어. 차체와 구동계, 센서 묶음(일반적으로 LiDAR, 카메라, 초음파 거리 센서, 관성 측정 장치(IMU), 실외라면 GNSS 수신기), 배터리 관리 시스템(BMS)을 갖춘 배터리, 잠금식 적재함, 조명·스피커·비상 정지 버튼.
2. 펌웨어. 모터 제어기, BMS 펌웨어, 센서 드라이버, 그리고 상위 소프트웨어를 기다리지 않고 모터 전원을 끊을 수 있는 저수준 안전 루프. 3단계가 정한 비상 정지 목표(모터 차단 100 ms 미만)는 결국 이 계층에서 달성된다.
3. 미들웨어. 로봇 컴퓨터 위의 메시징·프로세스 프레임워크. 표준의 README는 참조 프레임워크로 ROS 2 Humble(Open Robotics)을 들고 있으며, 많은 로봇이 센서 토픽, 좌표 변환, 내비게이션 노드에 ROS 2를 쓴다. ROS 좌표계 규칙 같은 미들웨어의 관례는 표준의 통신 관례와 같지 않다. 제2장에서 변환에 지면을 할애하는 이유이다.
4. 자율 주행 애플리케이션. 측위와 지도 작성, 인지와 장애물 추적, 전역·지역 경로 계획, 행동 상태 기계, 배송 업무 흐름(인수·이동·인도).
5. 클라우드 플릿 플랫폼. 플릿 관리자, 경로 최적화기, 분석 엔진, 운영자 대시보드, 고객용 배송 조회, 충전 관리, 소프트웨어 업데이트. 로봇과는 메시지 브로커로, 업무 시스템과는 API로 연결된다.

WIA ROB-010은 이 계층들의 내부를 어떻게 만들라고 말하지 않는다. 표준이 정하는 것은 계층 사이의 인터페이스와, 자율 주행 계층이 지켜야 할 몇 가지 행동 규칙이다. 그림 1-1은 네 단계를 이 구조 위에 겹쳐 놓은 것이다.

+--------------------------------------------------------------------+
|  CLOUD FLEET PLATFORM  (클라우드 플릿 플랫폼)                      |
|  fleet manager | route optimiser | analytics | operator dashboard  |
|     ^  Phase 4: 텔레메트리 토픽, 배차, 충전, OTA                   |
|     |  Phase 2: REST /api/v1/... (인증, 로봇, 패키지, 경로)        |
+-----|--------------------------------------------------------------+
      |   MQTT / HTTPS  -- 페이로드는 Phase 1 JSON 문서
+-----v--------------------------------------------------------------+
|  AUTONOMY APPLICATION  (자율 주행 애플리케이션)                    |
|  localization | perception | planning | behaviour state machine    |
|     Phase 3: 측위, 장애물 처리, A* / DWA,                          |
|              횡단보도·보도 규칙, 비상 정지                         |
+--------------------------------------------------------------------+
|  MIDDLEWARE  (예: ROS 2)   -- 내부 토픽, 표준화 대상 아님          |
+--------------------------------------------------------------------+
|  FIRMWARE    모터 제어, BMS, 저수준 안전 루프                      |
+--------------------------------------------------------------------+
|  HARDWARE    차체, LiDAR, 카메라, 초음파, IMU, GNSS,               |
|              배터리, 적재함, 비상 정지 버튼                        |
+--------------------------------------------------------------------+
  Phase 1(데이터 형식)은 로봇 밖으로 나가는 모든 화살표에 걸쳐 있다.

이 그림에서 두 가지를 읽어 낼 수 있다. 첫째, 1단계는 독립된 계층이 아니다. 로봇 경계를 넘는 모든 연결—MQTT 텔레메트리, REST 응답, 저장 기록—에서 쓰이는 어휘이다. 둘째, 미들웨어 계층은 의도적으로 건드리지 않는다. ROS 2에 투자한 팀이 내부 토픽을 바꿀 필요는 없다. 필요한 것은 로봇 가장자리에서 내부 메시지를 1단계 문서로 바꾸는 변환 단계뿐이다. 이렇게 분리해 두었기에 로봇 소프트웨어가 계속 발전하더라도 표준은 안정적으로 유지된다.

1.3 상호운용성 문제

대규모 주거 단지, 병원 캠퍼스, 도시의 한 구역에서 배송을 운영하는 사업자를 생각해 보자. 시간이 흐르면서 이 사업자는 여러 제조사의 로봇을 들이게 된다. 실외 통로용 모델 하나, 엘리베이터를 타는 실내용 모델 하나, 나중에 온도 관리 화물 때문에 추가로 산 모델 하나. 공통 계약이 없으면 모델마다 자기만의 생태계가 딸려 오고, 사업자는 다음과 같은 차이를 맞닥뜨린다.

한 줄씩 떼어 놓고 보면 사소한 통합 작업처럼 보인다. 그러나 모두 합치면 여러 제조사의 로봇을 하나의 대시보드, 하나의 배차 알고리즘, 하나의 고객 조회 화면 뒤에 두는 일이 사실상 불가능해진다. 비용은 시간이 갈수록 불어난다. 어느 제조사든 펌웨어를 갱신할 때마다 어댑터가 깨질 수 있고, 새 로봇 모델이 들어올 때마다 어댑터가 하나 더 필요하다.

안전의 측면도 있다. 운영 센터가 로봇의 오류 상태 진입, GPS 상실, 충전 복귀가 필요한 배터리 수준 도달을 한 가지 방식으로 알 수 없다면 혼합 플릿을 믿을 만하게 감독할 수 없다. 감사의 측면도 있다. 건물 관리자, 보험사, 당국은 로봇이 무엇을 했는지에 대한 증거를 점점 더 요구하는데, 증거는 모양이 같아야 서로 비교할 수 있다.

데이터 계약이 로봇을 똑같이 만들지는 않는다. 제조사는 여전히 하드웨어, 인지 성능, 배터리 수명, 가격으로 경쟁한다. 계약이 하는 일은 교환을 예측 가능하게 만드는 것이다. 한 번 작성한 플릿 플랫폼이 적합한 로봇이라면 무엇이든 감독할 수 있고, 고객용 애플리케이션은 어느 기계가 물건을 싣고 있든 같은 패키지 상태를 보여 줄 수 있다.

1.4 표준의 구성

WIA ROB-010은 네 개의 규범 단계 문서로 발행되었으며, 모두 버전 1.0.0, 상태 "Stable"이다. 각 단계 문서는 비규범적 부속서 세 개로 끝난다. 표 1-4는 이 책을 읽는 동안 가장 자주 돌아오게 될 지도이다.

단계 사이의 의존 관계

단계들은 각각 앞 단계를 딛고 선다는 의미에서 층을 이룬다. 2단계 응답은 1단계 객체를 싣는다. 3단계의 행동은 mode, errors, position.source 같은 1단계 필드로 보고된다. 4단계 텔레메트리는 말 그대로 "JSON으로 인코딩된 RobotState(1단계 참조)"이다. 그러므로 구현자는 표준을 단계적으로 채택할 수 있다. 먼저 유효한 1단계 문서를 내보내고, 다음으로 2단계 API를 열고, 3단계 행동을 문서화한 뒤, 마지막으로 4단계 플릿 플랫폼에 연결하는 식이다. 제8장에서 이를 채택 점검표로 정리한다.

규범 본문과 부속서

각 단계 문서의 끝에는 명시적으로 비규범적인 부속서 세 개가 붙어 있다.

• 부속서 E — 구현 참고 사항. 운용 범위 선언, 스키마 진화, 감사 기록 보존, 시각 동기화(NTPv4, 결정론적 인터록이 필요한 곳은 PTP), 월간 오류 예산 보고에 관한 현장 지침.
• 부속서 F — 채택 로드맵. Stable·Provisional·Reference의 세 안정성 등급을 정의하고, 주 버전이 바뀔 때 최소 90일의 병행 기간을 약속한다.
• 부속서 G — 시험 벡터와 적합성 증거. 긍정·부정 시험 벡터, Sigstore로 서명하는 증거 패키지, 분기별 재발행, 기록된 사유 없이 건너뛴 시험은 실패로 본다는 규칙을 설명한다.

부속서는 쓸모가 있지만 현행 본문에서 일관성이 가장 떨어지는 부분이기도 하다. 부속서는 적합성 등급에 관해 "부속서 A"를, 또 "부속서 D"를 언급하는데 두 부속서 모두 어느 단계 문서에도 존재하지 않는다. 또 필드 이름을 바꾸거나 삭제하면 부(minor) 버전을 올린다는 부속서 E의 문장은, 호환성을 깨는 변경에는 주(major) 버전을 올린다는 1단계의 버전 규칙과 충돌한다. 이 책은 이런 공백이 문제가 되는 곳마다 짚고 더 안전한 해석을 권한다. 이 경우 제3장은 이름 변경이나 삭제를 모두 주 버전 변경으로 다룰 것을 권고한다.

적합성 등급

README는 세 가지 적합성 등급을 제시한다. Surface는 데이터 형식을 다룬다. Verified는 여기에 연 1회 제3자 감사를 더한다. Anchored는 지속적으로 증거 패키지를 공개하는 것을 뜻한다. 이 등급은 적합성 주장에 얼마만큼의 보증이 뒷받침되는지를 나타낼 뿐, 로봇의 성능 수준을 나타내지 않는다. 각 등급이 실무에서 무엇을 요구하는지는 제7장에서 설명한다.

식별자에 관한 참고

네 개의 규범 단계 문서는 제목이 "WIA ROB-010"이다. 같은 패키지의 README와 OpenAPI 파일은 WIA-ROBOT-005라는 별칭을 쓴다. 예를 들어 OpenAPI의 서버 경로는 /wia-robot-005/v1이다. 두 이름은 같은 배송 로봇 표준을 가리킨다. 이 책은 규범 본문에 적힌 이름인 WIA ROB-010을 일관되게 쓰고, 별칭은 제4장에서 OpenAPI 파일을 다룰 때 한 번 더 언급한다. 조달 문서나 적합성 문서를 작성할 때는 두 형태를 한 번씩 함께 적어 두어, 어느 이름으로 검색하는 독자든 문서를 찾을 수 있게 하는 것이 좋다.

1.5 인접 표준과 WIA ROB-010의 관계

데이터 표준을 안전 인증으로 오해하는 경우가 흔하다. WIA ROB-010은 데이터·프로토콜 계층이다. 로봇과 플랫폼이 서로 무엇을 주고받는지, 그리고 그 교환에서 관찰할 수 있어야 하는 몇 가지 행동을 정한다. 로봇이 기계적·전기적으로 안전하다는 것을 인증하지 않으며, 이 표준에 적합하다고 해서 제품 안전성 평가를 대신할 수도 없다. README는 이 표준이 호환을 지향하는 여러 틀을 나열하는데, 표 1-5는 각각의 관계를 요약한 것이다.

실무 원칙은 프로젝트를 계획할 때 두 트랙을 분리해 두는 것이다. 제품 안전 트랙(위험 분석, 정지 회로의 기능 안전, 전기·배터리 안전, 국가 인증)은 안전 사례(safety case)를 만들어 낸다. ROB-010 트랙은 데이터와 인터페이스에 대한 적합성 증거를 만들어 낸다. 비상 정지 지연 측정처럼 두 트랙 모두에 쓰이는 산출물도 있지만, 한쪽의 인증서가 다른 쪽을 대신하는 일은 없다. 이 구분은 제7장에서 자세히 다룬다.

README에 나열된 표준 외에도 단계 문서들은 널리 알려진 공학 규격을 참조한다. 데이터 정의에는 JSON Schema draft 2020-12, 권한 부여에는 OAuth 2.0, REST 인터페이스 기술에는 OpenAPI, 텔레메트리에는 MQTT, 데이터 보호에는 TLS 1.3과 AES-256, 시각 동기화에는 NTPv4나 PTP를 쓴다. 어느 것도 로봇 전용이 아니라는 점이 오히려 강점이다. 대부분의 팀이 이미 이들을 다룰 도구를 갖추고 있기 때문이다.

1.6 규제 환경 개관

배송 로봇을 규율하는 법은 나라마다, 때로는 도시마다 다르고 계속 바뀐다. 그래서 이 절은 읽는 시점에 이미 낡았을 수도 있는 수치를 인용하는 대신, 배치 현장에서 대개 마주치는 규칙의 종류를 설명한다.

공공 공간 운행 허가

실외 배송 로봇은 법이 보통 보행자에게 배정해 둔 공간을 쓴다. 그래서 많은 관할 구역이 로봇이 공공 보도를 다니기 전에 허가, 시범 사업, 등록, 인증 제도 같은 형태의 승인을 요구한다. 조건에는 운행 장소와 시간, 속도, 무게, 원격 운영자의 개입 가능 여부, 보험, 로봇을 대중에게 식별시키는 방법 등이 포함될 수 있다. 실내나 사유 캠퍼스에서의 운행은 대개 소유자의 규칙과 일반적인 제품 안전·산업 안전 법규가 규율한다.

한국에서는 「지능형 로봇 개발 및 보급 촉진법」이 실외 이동 로봇의 운행안전인증 제도를 두고 있고, 「도로교통법」은 그런 로봇의 보도 통행을 이 인증과 연계하고 있다. 세부 요건, 인증 기관의 절차, 수치 기준은 2차 요약 자료가 아니라 국가법령정보센터(law.go.kr)에 게시된 현행 공식 법령과 인증 기관의 안내를 근거로 삼아야 한다. WIA ROB-010 적합성은 이 인증의 일부가 아니며 이를 대신하지도 않는다.

차도 횡단과 교통 규칙

로봇이 차도를 건너는 곳에서는 횡단보도에 관한 지역 교통 규칙이 적용된다. 표준의 3단계는 보수적인 횡단 절차를 담고 있다. 횡단보도를 인식하고, 신호를 확인하고, 접근 차량을 살피고, 의도를 알리고, 1–2 m/s로 건너며, 로봇에게 통행 우선권이 있더라도 양보한다. 또 보도 예절 규칙으로 "가능하면 왼쪽으로 추월"을 제시하는데, 제5장에서 설명하듯 어느 쪽으로 비켜 가는지는 지역 관습의 문제이므로 코드에 박아 넣지 말고 관할 구역별로 설정할 수 있게 해야 한다.

개인정보와 카메라 데이터

카메라를 단 로봇은 촬영에 동의하지 않은 사람들을 기록한다. 사람을 식별할 수 있는 영상에는 EU 일반 개인정보 보호법(GDPR)이나 한국의 「개인정보 보호법」 같은 개인정보 보호 법제가 적용된다. 표준의 4단계는 이에 관한 실무를 정해 두었다. 영상을 클라우드에 올리기 전에 얼굴을 흐리게 처리하고, 꼭 필요한 데이터만 수집하며, 보존 기간이 지난 텔레메트리는 자동 삭제한다(명세의 예시는 90일). 1단계도 센서 페이로드에 원본 프레임 대신 탐지 결과와 image_url을 싣도록 권고함으로써 이를 뒷받침한다. 제6장에서는 텔레메트리 보존과 감사 증거 보존의 차이를 포함해 보존 문제를 더 깊이 다룬다.

접근성과 사회적 수용

보도는 휠체어 이용자, 시각 장애인, 유모차를 미는 보호자, 천천히 걷는 노인이 함께 쓰는 공간이다. 당국과 건물 관리자는 로봇이 경사로, 출입문, 점자 블록을 막지 않는지를 주의 깊게 본다. 휠체어·유모차 주변 2.0 m의 여유 거리, 경사로와 출입문을 절대 막지 않는다는 규칙 같은 3단계의 안전 여유 거리는 이 때문에 존재한다. 사회적 쟁점은 제8장에서 다시 다룬다.

1.7 이 책을 읽는 방법

학습 경로

각 장은 앞 장을 딛고 서지만, 독자에 따라 다른 경로로 읽을 수 있다.

• 로봇 소프트웨어 엔지니어는 제2장(측위·인지), 제3장(스키마), 제5장(내비게이션 행동)을 꼼꼼히 읽고, 시험은 제7장을 본다.
• 플릿 플랫폼·백엔드 개발자는 제3장(스키마), 제4장(REST API), 제6장(플릿 통합)에 집중한다.
• 운영 사업자의 통합 담당자—건물 관리, 캠퍼스 서비스, 물류·음식 배달 사업자—는 이 장을 읽고, 제3장과 제4장은 어휘 위주로 훑은 뒤 제6장과 제8장을 읽는다.
• 품질 보증·인증 담당자는 제7장을 먼저 읽고, 거기서 점검하는 개별 요구사항은 제3~6장을 찾아본다.

표기 규칙

요구 수준을 나타내는 용어는 IETF 문서의 관례(RFC 2119, RFC 8174)를 따른다. MUST와 MUST NOT은 절대적 요구사항, SHOULD와 SHOULD NOT은 타당한 이유가 있으면 벗어날 수 있는 강한 권고, MAY는 선택 사항이다. 이 책이 요구사항을 인용할 때는 "3단계 §6.1"처럼 단계와 절을 밝힌다. 저자 자신의 권고를 제시할 때는 그렇다고 분명히 적는다. 필드 이름, 열거값, API 경로, 토픽 이름은 코드 글꼴로 쓰며 번역하지 않는다. "명세 목표"라고 표시한 수치는 규범 단계 문서에서 가져온 것이고, "일반적" 또는 "예시"라고 표시한 수치는 설명을 위한 것일 뿐 요구사항이 아니다.

책 전체에서 쓰는 예시 식별자

장마다 예시를 비교할 수 있도록 이 책은 로봇 하나, 패키지 하나, 경로 하나만 쓴다. 아래 식별자는 버전 4 형식의 UUID이다. 로봇 ID는 2단계와 4단계 예시에 쓰인 값이고 패키지 ID와 경로 ID는 이 책을 위해 임의로 만든 값이며, 위치는 시뮬레이터에 표시되는 것과 같은 서울 도심의 예시 좌표이다.

{
  "robot_id":   "550e8400-e29b-41d4-a716-446655440000",
  "package_id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "route_id":   "3b241101-e2bb-4255-8caf-4136c566a962",
  "example_position": { "latitude": 37.5665, "longitude": 126.9780 },
  "schema_version": "1.0.0"
}

이것은 1단계 문서가 아니라 참조용 카드일 뿐이다. 제3장은 이 식별자들로 완전한 RobotState, Package, Route 문서를 만들고, 제4장은 API 호출에 이들을 쓰며, 제6장은 MQTT로 이들을 발행한다. 예시를 자신의 시험용으로 고칠 때는 직접 만든 UUID로 바꾸고, 예시 식별자를 운영 데이터에 재사용해서는 안 된다.

이 책이 하지 않는 일

이 책은 버전 1.0.0으로 발행된 표준을 설명하고, 본문이 불완전하거나 앞뒤가 맞지 않는 곳을 지적한다. 표준에 없는 요구사항을 지어내지 않는다. 표준이 비워 둔 부분의 모양을 제안할 때—가장 두드러진 예는 제8장의 미션 매니페스트와 인수인계 이벤트이다—그 제안에는 비규범적이라는 표시를 붙인다. 시장 전망과 보급 통계도 다루지 않는다. 금방 낡고, 검증할 수 있는 경우가 드물기 때문이다. 목표는 독자가 표준 자체의 본문만으로 적합한 시스템을 만들고, 시험하고, 논증할 수 있게 하는 것이다.

장 요약

• WIA ROB-010은 잠금식 적재함에 물건을 싣고 라스트마일을 주행하는 저속 바퀴형 로봇을 대상으로 하며, 실외 보도·캠퍼스·실내 환경을 모두 포괄한다.
• 이런 로봇은 하드웨어에서 클라우드까지 다섯 계층으로 이루어진다. 표준은 계층 사이의 교환—특히 로봇 밖으로 나가는 모든 것—과 관찰 가능한 일부 행동을 정할 뿐, 내부 구현은 정하지 않는다.
• 핵심 문제는 상호운용성이다. 공통 계약이 없으면 다중 제조사 운영자는 식별, 위치, 단위, 모드, 패키지, 명령, 안전 상태, 텔레메트리 각각에 대해 제조사마다 통합 작업을 해야 한다.
• 표준은 네 단계—데이터 형식, API 인터페이스, 내비게이션 프로토콜, 플릿 통합—와 적합성 등급(Surface·Verified·Anchored), 비규범적 부속서 E~G로 구성된다. 규범 문서는 "WIA ROB-010", README와 OpenAPI 파일은 별칭 WIA-ROBOT-005를 쓴다.
• WIA ROB-010은 데이터·프로토콜 계층으로서 ISO 13482 같은 제품 안전 표준이나 국가의 운행 허가를 보완할 뿐, 결코 대신하지 않는다.
• 규제는 장소와 시기에 따라 다르다. 지역 운행 허가, 횡단보도의 교통 규칙, 카메라 데이터에 대한 개인정보 보호 의무, 함께 쓰는 보도의 접근성을 계획에 반영해야 한다.

인덱스로 돌아가기 | 제2장: 위치·인지의 기초 — 로봇 상태를 숫자로 표현하기 →