ABB ConCerT가 약속한 것은 로봇 한 대의 법적 인증을 버튼 한 번으로 끝내는 일이 아니다. ABB의 2026년 2월 발표는 페인트 로봇의 안전 관련 software module 시험에 약 11 engineer-days가 걸리던 절차를 cloud simulation과 실물 검증을 결합해 하루 미만으로 줄이려는 연구 목표를 설명한다.
성공 여부는 빠르게 많은 simulation을 돌렸는지가 아니라 virtual fault가 실물 controller와 robot에서 같은 안전 반응을 만들고, 변경 뒤 추적 가능한 증거가 남는지로 판단해야 한다. 현재 확인된 상태는 노르웨이 연구위원회 지원을 받은 프로젝트이며 공인 인증기관의 최종 승인이나 모든 ABB 로봇의 상용 continuous certification 기능은 아니다.
공개된 능력은 ‘안전 모듈 시험 자동화 연구’다
ABB의 ConCerT 공식 발표는 Research Council of Norway 1,600만 NOK와 ABB의 같은 규모 투자를 합쳐 3,200만 NOK 프로젝트라고 설명한다. 목표는 safety-critical software를 자동·지속적으로 시험하는 방법을 개발하는 것이며 초기 대상은 paint robot이다.
11일에서 하루 미만이라는 수치는 현재 수동 engineer effort와 프로젝트 목표의 비교다. module 수, test case 수, 반복 횟수, 포함된 report·review 시간과 독립 검증이 공개되지 않았다. 따라서 전체 robot certification, site integration 승인 또는 규제기관 처리 기간이 90% 이상 줄었다고 계산하지 않는다.
continuous라는 말도 deployment 중 무조건 자동 승인한다는 뜻으로 읽지 않는다. software change마다 영향 범위와 test suite를 정하고 simulation·hardware evidence를 다시 만들어 review 가능한 상태를 유지하는 방향으로 이해해야 한다. safety case의 승인 책임과 적용 표준은 여전히 별도다.
시험 조건은 software 변경과 물리 반응을 함께 묶어야 한다
첫 조건은 version identity다. source commit, build, compiler, safety parameter, controller firmware와 robot hardware configuration을 test run에 묶는다. 둘째는 environment identity다. simulation model, network timing, sensor·actuator fault와 실물 Bryne rig의 calibration을 기록한다. 같은 이름의 module이라도 build와 hardware가 다르면 증거를 재사용할 수 없다.
| 위험·오류 | 가상 주입 조건 | 실물 확인 | 통과로 보지 않을 경우 |
|---|---|---|---|
| 통신 지연·손실 | 지연 분포와 packet loss를 경계값까지 주입 | controller timeout·safe state와 실제 정지시간 측정 | simulation만 정지하거나 실물이 위험 명령을 유지 |
| sensor stuck·drift | 고정값, 점진 편향과 불일치 채널 생성 | diagnostic detection, fallback·alarm 확인 | 검출되지 않거나 잘못된 정상 복귀 |
| actuator·brake 이상 | response delay와 제한된 torque model | 허용 장비에서 안전 절차 아래 physical response 확인 | model과 실물의 stop envelope가 다름 |
| software regression | 변경 전후 전체 suite와 경계 조합 재실행 | 선정된 critical case를 실물에서 재현 | 실패를 제외하거나 report trace가 끊김 |
이 표는 프로젝트의 공개 test list가 아니라 발표된 fault injection·cloud simulation·physical test 방식을 안전 case로 연결하는 검증 틀이다. 실제 위험 주입은 설비·사람을 보호하는 통제 아래 수행해야 한다. 위험한 fault를 production cell에 직접 넣는 방식으로 오해해서는 안 된다.
희귀 조합과 모델 불일치가 edge case다
안전 실패는 흔히 단일 고장보다 경계 조합에서 나타난다. network delay가 커진 순간 sensor drift가 겹치거나, robot이 특정 pose·payload에 있을 때 reset이 들어오는 경우다. cloud 병렬 simulation은 이런 조합을 넓게 탐색할 수 있지만 조합 생성 규칙과 coverage metric이 없으면 많은 run도 같은 쉬운 case를 반복할 수 있다.
simulation fidelity도 시험 대상이다. brake dynamics, controller scheduling, fieldbus jitter와 paint process의 hose·tool load가 실물과 다르면 잘못된 통과 또는 잘못된 실패가 생긴다. 실물 Bryne test 결과가 simulation model을 어떻게 보정했는지, model version이 다음 run에 반영됐는지 추적해야 한다.
AI가 test case를 생성하거나 우선순위를 정하더라도 acceptance oracle은 명확해야 한다. 안전 요구사항에서 예상한 state, timing과 diagnostic output을 machine-checkable assertion으로 만들고 human reviewer가 요구사항 추적성을 확인한다. 생성형 모델이 plausible한 test를 썼다는 이유로 안전 요구를 만족했다고 보지 않는다.
실패 행렬은 발견 주체와 복구 책임을 분리한다
실패는 test infrastructure, simulation model, software-under-test, physical rig와 requirement definition으로 나눈다. 예를 들어 virtual robot만 늦게 멈췄다면 product defect가 아니라 model timing 오류일 수 있다. 반대로 simulation은 통과하지만 실물이 늦게 멈추면 product 또는 fidelity gap을 조사해야 한다. 모든 red result를 같은 defect queue에 넣으면 원인과 재시험이 흐려진다.
| 관찰 결과 | 첫 책임 주체 | 필수 보존물 | 재개 조건 |
|---|---|---|---|
| 가상 실패·실물 통과 | simulation/model 담당 | model checksum, trace, 실물 측정 | fidelity 수정 후 suite 재실행 |
| 가상 통과·실물 실패 | safety software·system 담당 | binary, controller log, physical timing | 원인 수정과 independent review |
| 둘 다 실패 | 요구·software 담당 공동 | requirement link, 두 환경 trace | 요구 충족과 regression 통과 |
| 결과 재현 불가 | test infrastructure 담당 | seed, environment, clock·resource log | deterministic replay 또는 변동 범위 정의 |
| 요구 판정 모호 | safety assurance 담당 | hazard·requirement·판정 기록 | oracle 승인 전 자동 통과 금지 |
owner는 문제를 혼자 해결한다는 뜻이 아니라 첫 triage와 증거 보존 책임이다. 안전 관련 실패를 자동 retry로 지워서는 안 된다. 변경한 code와 model, reviewer, 재시험 결과가 원래 hazard와 연결돼야 continuous evidence가 된다.
복구 지표는 하루라는 속도보다 증거의 완전성이다
시간 지표는 test 요청부터 결과 생성, triage, 수정, 실물 재시험과 review 승인까지 나눈다. 하루 미만 목표가 raw execution인지 engineer effort인지 end-to-end인지 공개 자료로 확정할 수 없으므로 프로젝트는 각 clock을 별도로 발표해야 한다. 빠른 execution 뒤 며칠간 수동 triage가 필요하면 전체 lead time은 줄지 않을 수 있다.
품질 지표는 requirement coverage, fault coverage, 가상·실물 일치율, flaky test 비율과 escaped defect다. 시험 통과율이 높다는 사실은 test가 쉬워졌다는 뜻일 수도 있다. 새 software 변경이 영향을 준 requirement를 빠짐없이 선택했고, 위험한 실패가 production 전에 잡혔는지를 본다.
회복 가능성도 핵심이다. test service 장애나 잘못된 model update 뒤 마지막 검증된 환경으로 rollback할 수 있어야 한다. report에는 원시 trace와 재현 seed, binary·model hash, reviewer decision을 남겨 공인 평가나 내부 audit에서 다시 확인할 수 있게 한다.
상용 확대의 go/no-go는 인증 완료와 분리한다
go 조건은 좁다. 특정 paint robot safety module과 hardware configuration에서 요구사항 추적, simulation·실물 correlation, 반복 가능한 fault injection과 독립 review가 닫혀야 한다. ISO 10218-1:2025 공식 기록처럼 적용 표준의 현행 판본과 요구 범위를 확인한 뒤에만 다음 module·robot family로 범위를 넓힌다. 다른 robot이나 site에는 새로운 hazard analysis와 실물 anchor test가 필요하다.
- 11 engineer-days 기준의 작업 범위, 포함 시간과 test case 분모를 공개한다.
- cloud run 수보다 requirement·hazard·fault coverage와 flaky rate를 함께 제시한다.
- 시뮬레이션 통과를 Bryne 실물 result와 trace ID로 연결하고 mismatch를 보존한다.
- AI가 만든 test와 acceptance oracle·human review의 책임을 분리한다.
- 연구 project milestone, 내부 qualification, 공인 certification과 site approval을 서로 다른 상태로 표시한다.
- 다른 robot family 확대 전에 hardware·tool·환경 변화에 대한 재검증 범위를 정한다.
no-go는 하루 목표를 못 맞춘 경우만이 아니다. result가 재현되지 않거나 virtual·physical mismatch가 설명되지 않고, requirement trace가 끊기면 속도가 빨라도 중단해야 한다. ConCerT의 가치가 입증되려면 ‘얼마나 빨리 통과했나’보다 ‘어떤 변경을 어떤 증거로 안전하다고 말할 수 있나’가 선명해져야 한다.
독자가 이어서 묻는 질문
ConCerT가 자동화돼도 사람은 어느 단계에서 개입해야 하나요?
안전 요구사항과 hazard를 승인할 때, AI나 도구가 만든 test와 판정 oracle을 검토할 때, simulation·실물 불일치를 triage할 때, 변경 후 최종 evidence를 승인할 때 사람이 책임져야 한다. 자동화는 반복 실행과 trace 수집을 줄일 수 있지만 공인 인증기관·manufacturer·integrator의 판단 책임을 대체하지 않는다.
클라우드 시험이 실패하면 ABB와 현장 운영자 중 누가 책임지나요?
실패 원인이 test infrastructure, simulation model, safety software, physical rig 또는 requirement인지 먼저 나눠야 한다. 제품 개발 단계에서는 ABB와 project partner의 책임이 중심이고, 상용 배치 뒤에는 공급사·integrator·site owner의 계약 경계를 별도로 정해야 한다. 자동 retry 전에 binary·model·trace·clock을 보존하고 재개 승인자를 지정해야 한다.
자료 마지막 확인: 2026년 8월 26일