How CrossnoKaye grounds physical AI with Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

CrossnoKaye는 ATLAS의 통합 설비 맥락과 Amazon Bedrock AgentCore의 격리된 Python 실행을 결합해, AURA가 산업 현장의 문제를 제어 논리와 실제 계산에 근거해 분석하도록 구현했다.

📌 핵심 요약

• 기존 산업 현장은 PLC·DCS·히스토리언·SCADA에 데이터와 제어 논리가 분산돼 외부 AI 에이전트의 접근이 어렵다. ATLAS는 설비 모델, 기본 제어 소프트웨어, 히스토리언, 최적화 애플리케이션을 통합하고, AURA는 단일 보안 경계 안에서 운영 상태에 접근한다.
• CrossnoKaye는 100곳이 넘는 산업 시설과 제어 대상 자산 13,000개에 걸쳐 22조 개가 넘는 기계 데이터 포인트를 저장하고, 매일 500억 개가 넘는 측정값을 수집하며, 1,000개가 넘는 APC 애플리케이션을 운영한다. 회사는 이 애플리케이션들이 생산 처리량을 11~17% 개선하고 시설 전체 에너지 비용을 평균 21% 줄인다고 보고한다.
• ATLAS의 현장 Kubernetes 클러스터는 기존 PLC·DCS를 활용해 기본 제어 로직을 실행하며, 클라우드 연결이 끊겨도 현장 제어를 유지한다. 클라우드 최적화 결과는 시설별 순서가 보장된 경로로 전달되며, CrossnoKaye는 하루 65만 건의 폐루프 제어 동작을 수행한다고 보고한다.
• AURA는 설비 연결 관계, 배포된 제어 로직과 인터록, 센서값 등을 함께 읽어 원인을 조사한다. LLM이 대규모 센서 데이터의 통계와 물리 수지를 안정적으로 계산하기 어렵다는 한계를 보완하기 위해 Amazon Bedrock AgentCore의 격리된 microVM에서 Python을 실행한다.
• AURA는 대화형 Chats, 반복 가능한 Tasks, 자동 감시 Routines를 제공한다. Chats는 15분 슬라이딩 TTL의 세션을 유지하고, Tasks와 Routines는 실행마다 새 microVM을 만든 뒤 계산 종료 즉시 세션을 중지해 재현성, 실행 간 상태 분리, 유휴 비용 관리를 지원한다.

🧩 주요 포인트

1. ATLAS가 운영 데이터와 제어 논리를 함께 관리함 → AURA는 센서의 시간적 선후관계뿐 아니라 실제 인터록의 인과관계를 따라 고장 원인을 분석할 수 있다.
2. 현장 기본 제어와 클라우드 최적화의 역할 분리 → 클라우드 연결이 끊겨도 현장 제어를 유지하면서 최적화 결과를 기존 PLC·DCS 설비에 적용하는 구조다.
3. Chats와 Tasks·Routines의 세션 수명 분리 → 대화에서는 분석 상태를 이어가고, 반복 실행에서는 이전 상태의 혼입을 방지한다. 생산 처리량 11~17% 개선과 에너지 비용 평균 21% 절감은 CrossnoKaye의 보고 수치로 구분해 해석해야 한다.

🧠 상세 정리

1. 산업 현장에서 외부 AI 연결이 어려운 이유

산업 시설에서는 PLC와 DCS가 장비 제어를 담당하고, 히스토리언은 현장마다 다른 태그 이름으로 시계열 데이터를 저장하며, SCADA는 운전 화면을 제공하는 등 기능이 여러 공급업체의 시스템에 나뉘어 있다. 별도의 최적화 도구와 경보 기록기까지 더해지면 외부 AI 에이전트가 서로 다른 명명 규칙과 데이터 구조를 연결해야 한다. 특히 장비의 실제 동작을 결정하는 제어 시퀀스, 상태 머신, 안전 인터록은 외부 도구가 들여다보기 어려운 독점 컨트롤러 코드 안에 들어 있다. 여러 OT 시스템에 접근 권한을 부여하려면 공장 네트워크에 자격 증명을 분산해야 하는 문제도 생긴다. 원문은 이러한 조건 때문에 기존 시스템 위에 외부 에이전트를 덧붙이는 방식이 실무에서 잘 작동하기 어렵다고 설명하며, 데이터와 제어 맥락을 함께 제공하는 접근의 필요성을 제시한다.

2. ATLAS의 통합 기반과 CrossnoKaye의 운영 규모

CrossnoKaye의 ATLAS는 식음료 공장, 산업용 냉동 시설, 골재 채석장, 제조 현장에서 실시간 데이터와 AI 추론을 장비의 폐루프 제어에 연결하는 소프트웨어 정의 자동화 플랫폼이다. ATLAS가 AWS에서 설비 모델, 기본 제어 소프트웨어, 히스토리언, 최적화 애플리케이션을 함께 관리하므로 AURA는 단일 보안 경계 안에서 공장의 전체 운영 상태에 접근할 수 있다. 회사는 100곳이 넘는 산업 시설과 제어 대상 자산 13,000개를 대상으로 22조 개가 넘는 기계 데이터 포인트를 저장하고 매일 500억 개가 넘는 새 측정값을 수집한다고 설명한다. 또한 1,000개가 넘는 실시간 고급 공정 제어(APC) 애플리케이션을 운영하며, 이들이 생산 처리량을 11~17% 높이고 시설 전체 에너지 비용을 평균 21% 줄인다고 보고한다. 이 성과는 CrossnoKaye가 제시한 수치이며, 제공된 원문에는 비교 기준이나 측정 방법의 상세 설명이 없다.

3. 클라우드 연결과 분리된 현장 기본 제어

ATLAS는 고객이 기존 공장 하드웨어를 철거하거나 교체하지 않고도 PLC·DCS 기반의 가마, 파쇄기, 건조실, 오븐, 냉동기, 밸브, 압축기 등을 제어하도록 설계됐다. 각 시설의 제어 패널은 컴퓨터, 전원 공급 장치, 네트워크 스위치를 이중화하고, 로컬 Kubernetes 클러스터에서 계약 우선 방식의 마이크로서비스를 실행한다. 클라우드에서 작성·검증·버전 관리한 기본 제어 로직에는 장비 상태 머신, 시퀀스, 운전 한계, 인터록, 경보 규칙이 포함되며, 이를 현장 장치에 내려받아 기존 장비와 컨트롤러를 대상으로 실행한다. 각 엣지 장치는 공장 내부에 인바운드 방화벽 포트를 열지 않는 아웃바운드 전용 IT/OT 게이트웨이로도 작동하고, Amazon VPC Lattice와 Amazon MSK를 통해 고빈도 데이터를 AWS로 보낸다. 클라우드 연결이 끊겨도 로컬 기본 제어는 계속 작동하며, CrossnoKaye는 연간 9,000건이 넘는 제어 소프트웨어 배포와 100만 시간이 넘는 가동 동안 안전 사고가 없었다고 보고한다.

4. 파생 계측값에서 폐루프 최적화까지

기본 제어 위에서는 동일한 설비 모델을 이용해 파생 엔지니어링 신호와 폐루프 최적화 애플리케이션이 작동한다. 클라우드의 Scheduling 시스템은 Amazon S3에 버전 관리된 Python 패키지를 바탕으로 두 개의 연속 파이프라인을 실행하며, 인스턴스별 주기와 공장 설정 변경에 따른 이벤트를 처리한다. 합성 계측 알고리즘은 열 흐름 분포, 자산 건전성 지수, 에너지 집약도, 질량 수지 편차 같은 지표를 계산해 물리적 입출력 값과 함께 히스토리언에 기록한다. 최적화 애플리케이션은 이 파생값에 물리 모델, 모델 예측 제어(MPC), 강화학습, 유틸리티 요금, 일기예보를 결합해 최적 설정값 일정을 산출한다. Amazon SQS FIFO 큐가 시설별 일정과 상태 업데이트의 순서를 보장한 뒤 현장 기본 제어로 설정값을 전달하며, CrossnoKaye는 이 구조에서 하루 65만 건의 폐루프 제어 동작이 수행된다고 설명한다.

5. 설비 맥락으로 파쇄기 장애의 인과관계 추적

AURA는 Amazon EKS의 마이크로서비스와 지속성 있는 Temporal 워크플로로 실행되며, 호출자의 기업 권한에 따라 Atlas Data 게이트웨이에서 운영 상태를 읽는다. 여기에는 상·하류 장비 연결 관계, 배포된 기본 제어 로직과 인터록, 물리·합성 계측값, 설정 변경과 경보 이력, 최적화 일정, Amazon Bedrock Knowledge Bases에 색인된 문서가 포함된다. 원문의 골재 채석장 사례에서는 한 근무조 동안 공장 후단이 두 번 정지했고, 히스토리언상 3차 파쇄기 뒤에 2차 파쇄기 오류가 발생해 파쇄기 자체의 문제처럼 보였다. AURA는 컨베이어 배치와 인터록을 함께 읽어 3차 파쇄기 아래 재순환 벨트의 미끄러짐이 과부하 인터록을 작동시키고, 이어 상류 안전 인터록이 2차 파쇄기를 멈추는 흐름을 추적했다. 공장 관리자는 작업자를 보내 벨트를 확인했고 수분 안에 미끄러짐을 확인·수리했으며, 이 사례는 경보의 시간 순서만으로는 드러나지 않는 원인을 제어 논리로 설명하는 가치를 보여준다.

6. 권한 확인부터 격리 계산과 결과 전달까지

엔지니어와 MCP 클라이언트의 요청은 AWS WAF와 공개 Application Load Balancer를 거치며, API 게이트웨이는 기업 SSO 또는 MCP 자격 증명을 검증한다. AURA 워크플로는 Atlas Data 게이트웨이에서 설비 상태를 읽고, Model Gateway를 통해 프롬프트와 조직 범위의 RAG 질의를 기반 모델, Amazon Bedrock Guardrails, Amazon Bedrock Knowledge Bases로 전달한다. 통계·열역학·다중 데이터셋 계산이 필요하면 입력 데이터를 gRPC로 내부 Sandbox Orchestrator에 보내고, 이 서비스가 AWS SDK를 사용해 Amazon Bedrock AgentCore의 격리된 코드 인터프리터 microVM에서 모델이 작성한 Python을 실행한다. 이는 LLM이 엔지니어링 맥락을 해석하고 조사를 계획하는 능력과, 수백만 센서값에 대한 신뢰할 수 있는 수치 계산을 구분해 구성한 것이다. 대화형 세션의 진행 상황은 Amazon ElastiCache for Valkey를 통해 스트리밍되며, 검증된 Apache Parquet 출력·차트·인용이 포함된 Brief는 AWS PrivateLink를 통해 Amazon S3에 저장되고 자동 Brief는 Amazon SES로 전달된다.

7. Chats·Tasks·Routines의 서로 다른 운영 목적

AURA는 Amazon Bedrock의 기반 모델과 Amazon Bedrock AgentCore Code Interpreter를 결합해 세 가지 운영 방식을 제공한다. Chats는 단일 장비, 공정 라인, 여러 사업장에 걸친 포트폴리오를 대상으로 여러 차례 대화하는 엔지니어링 분석이며, 한 번의 대화 턴에서 최대 200개 시설을 다룰 수 있다고 설명한다. Tasks는 변경 불가능한 버전 스냅샷에 연결된 반복 가능하고 매개변수화된 조사로, 근거 표와 차트의 인용을 포함하는 구조화된 기술 Brief를 생성한다. Routines는 일정, 센서 임계값, 변화율 구간, 경보, 장비 운전 모드 전환에 따라 자동으로 실행되는 백그라운드 감시 기능이다. 이 구분은 사용자가 가설을 바꾸며 탐색하는 대화와 동일한 조건에서 반복 수행해야 하는 조사가 서로 다른 실행 상태 관리를 요구한다는 다음 설계 논점으로 이어진다.

8. 대화 상태 유지와 반복 실행의 재현성

Chats에서는 엔지니어가 데이터를 불러오고 특정 경보를 제외한 뒤 다른 변수와 상관관계를 조사하므로, 매 턴 새 샌드박스를 만들면 메모리의 표가 사라지고 지연이 늘어난다. 이에 Sandbox Orchestrator는 Amazon ElastiCache for Valkey에서 대화와 하나의 유지된 AgentCore 세션을 연결하고 15분 슬라이딩 TTL을 적용하며, 유휴 시간이 만료된 뒤 사용자가 돌아오면 대체 세션을 마련한다. Tasks와 Routines는 매번 새 일회용 microVM에서 시작하고 계산이 끝나면 StopCodeInterpreterSession으로 즉시 종료해 이전 실행의 상태 혼입과 유휴 샌드박스 요금을 방지한다. 이어지는 사례에서는 94개 시설의 최근 24시간 주요 경보를 불러와 시설·규칙·발생 간격별로 묶고, 단순 경보 건수 순위 대신 반복 경보의 성격을 구분하는 Python 분석을 설명한다. 다만 제공된 원문은 103건의 주요 경보가 두 개의 반복적인 덤프 탱크 수위 관련 항목에서 발생했다는 설명 도중 잘려 있어, 그 사례의 최종 위험 분류와 후속 결과는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 채석장 사례에서 진단의 핵심은 경보 데이터의 양보다 설비 연결 관계와 실제 인터록을 함께 해석하는 데 있었다. 통합된 제어 맥락은 연쇄 정지의 결과를 최초 원인으로 오인할 가능성을 줄인다.
• AURA는 LLM의 조사 계획·맥락 해석과 Python의 수치 계산을 결합한다. 격리된 실행 환경은 계산을 수행하는 기반이며, 수치 답변의 근거는 실제 데이터에 대한 계산 결과에서 나온다.
• 현장 제어의 지속성, 대화 상태의 연속성, 반복 작업의 재현성은 서로 다른 계층에서 다뤄진다. 원문은 각 목적에 맞춰 현장 기본 제어와 샌드박스 수명을 설계하는 접근을 보여준다.

✅ 액션 아이템

• ATLAS와 AURA의 적용 검토에서 설비 모델·기본 제어 로직·히스토리언의 통합 범위와 단일 보안 경계 내 접근 방식을 확인.
• CrossnoKaye가 보고한 생산 처리량 11~17% 개선과 에너지 비용 평균 21% 절감의 측정 기준 및 적용 조건을 확인.
• Chats의 15분 슬라이딩 TTL과 Tasks·Routines의 실행별 새 microVM 방식을 분석 상태 유지 및 재현성 요구에 맞춰 검토.

❓ 열린 질문

• CrossnoKaye가 보고한 생산 처리량 11~17% 개선과 에너지 비용 평균 21% 절감은 어떤 비교 기준과 측정 조건에서 산출됐는가?
• ATLAS의 단일 보안 경계 안에서 AURA가 접근하는 설비 모델·제어 로직·센서값의 권한 범위는 어떻게 정해지는가?
• Chats의 15분 슬라이딩 TTL이 만료돼 세션을 교체할 때 이전 분석 상태는 어떻게 처리되는가?