제퍼넷 로고

생성 데이터 인텔리전스

빅 데이터

Apache Flink용 Amazon Managed Service를 사용한 Krones 실시간 생산 라인 모니터링 | 아마존 웹 서비스

플라톤에 의해 재발행
플라톤에 의해 재발행

시간

조회 수 : 59

크로네 전 세계의 양조장, 음료수 병 제조업체 및 식품 생산업체에 개별 기계와 완전한 생산 라인을 제공합니다. 매일 수백만 개의 유리병, 캔, PET 용기가 크로네스 라인을 통과합니다. 생산 라인은 라인을 정지시키고 생산 수율을 감소시킬 수 있는 오류가 많이 발생하는 복잡한 시스템입니다. Krones는 오류를 가능한 한 빨리(때로는 오류가 발생하기 전에) 감지하고 생산 라인 운영자에게 알리고 신뢰성과 생산량을 높이려고 합니다. 그렇다면 실패를 어떻게 감지할 수 있을까요? Krones는 라인에 데이터 수집을 위한 센서를 장착하고 이를 규칙에 따라 평가할 수 있습니다. 라인 제조업체인 Krones와 라인 운영자는 기계에 대한 모니터링 규칙을 만들 수 있습니다. 따라서 음료수 병 제조업체 및 기타 운영자는 라인에 대한 자체적인 오차 한계를 정의할 수 있습니다. 과거 Krones는 시계열 데이터베이스 기반 시스템을 사용했습니다. 주요 과제는 이 시스템을 디버깅하기 어렵고 쿼리가 기계의 현재 상태를 나타내지만 상태 전환은 나타내지 않는다는 점이었습니다.

이 게시물은 Krones가 다음을 기반으로 라인을 모니터링하기 위해 스트리밍 솔루션을 구축한 방법을 보여줍니다. 아마존 키네 시스 과 Apache Flink용 Amazon 관리형 서비스. 이러한 완전 관리형 서비스는 Apache Flink를 사용하여 스트리밍 애플리케이션을 구축하는 복잡성을 줄여줍니다. Apache Flink용 관리형 서비스는 내구성 있는 애플리케이션 상태, 지표, 로그 등을 제공하는 기본 Apache Flink 구성 요소를 관리하며, Kinesis를 사용하면 모든 규모의 스트리밍 데이터를 비용 효율적으로 처리할 수 있습니다. 자신만의 Apache Flink 애플리케이션을 시작하고 싶다면 다음을 확인하세요. GitHub 저장소 Flink의 Java, Python 또는 SQL API를 사용하는 샘플의 경우.

솔루션 개요

Krones의 라인 모니터링은 크로네 매장 안내 체계. 이는 회사의 모든 활동에 대한 조직, 우선 순위 지정, 관리 및 문서화에 대한 지원을 제공합니다. 이를 통해 작업자가 라인 어디에 있든 관계없이 기계가 정지되거나 자재가 필요한 경우 작업자에게 알릴 수 있습니다. 검증된 상태 모니터링 규칙은 이미 내장되어 있지만 사용자 인터페이스를 통해 사용자가 정의할 수도 있습니다. 예를 들어, 모니터링되는 특정 데이터 포인트가 임계값을 위반하는 경우 해당 라인에 유지 관리 주문에 대한 텍스트 메시지나 트리거가 있을 수 있습니다.

상태 모니터링 및 규칙 평가 시스템은 AWS 분석 서비스를 사용하여 AWS에 구축되었습니다. 다음 다이어그램은 아키텍처를 보여줍니다.

Krones 생산 라인 모니터링을 위한 아키텍처 다이어그램

거의 모든 데이터 스트리밍 애플리케이션은 데이터 소스, 스트림 수집, 스트림 스토리지, 스트림 처리 및 하나 이상의 대상이라는 5개 계층으로 구성됩니다. 다음 섹션에서는 각 계층에 대해 더 자세히 알아보고 Krones가 구축한 라인 모니터링 솔루션이 어떻게 작동하는지 자세히 알아봅니다.

데이터 소스

데이터는 Siemens S7 또는 OPC/UA와 같은 여러 프로토콜을 읽는 에지 장치에서 실행되는 서비스에 의해 수집됩니다. 원시 데이터는 통합된 JSON 구조를 생성하기 위해 사전 처리되며, 이를 통해 나중에 규칙 엔진에서 더 쉽게 처리할 수 있습니다. JSON으로 변환된 샘플 페이로드는 다음과 같습니다.

{
  "version": 1,
  "timestamp": 1234,
  "equipmentId": "84068f2f-3f39-4b9c-a995-d2a84d878689",
  "tag": "water_temperature",
  "value": 13.45,
  "quality": "Ok",
  "meta": {      
    "sequenceNumber": 123,
    "flags": ["Fst", "Lst", "Wmk", "Syn", "Ats"],
    "createdAt": 12345690,
    "sourceId": "filling_machine"
  }
}

스트림 수집

AWS IoT 그린그래스 오픈 소스 IoT(사물 인터넷) 에지 런타임 및 클라우드 서비스입니다. 이를 통해 로컬에서 데이터에 대한 작업을 수행하고 장치 데이터를 집계 및 필터링할 수 있습니다. AWS IoT Greengrass는 엣지에 배포할 수 있는 사전 구축된 구성 요소를 제공합니다. 생산 라인 솔루션은 데이터를 처리하고 다음과 같은 AWS 대상으로 전송할 수 있는 스트림 관리자 구성 요소를 사용합니다. AWS IoT 분석, 아마존 단순 스토리지 서비스 (Amazon S3) 및 Kinesis. 스트림 관리자는 레코드를 버퍼링하고 집계한 다음 이를 Kinesis 데이터 스트림으로 보냅니다.

스트림 저장

스트림 저장소의 역할은 내결함성 방식으로 메시지를 버퍼링하고 하나 이상의 소비자 애플리케이션에서 사용할 수 있도록 하는 것입니다. AWS에서 이를 달성하기 위해 가장 일반적인 기술은 Kinesis와 Apache Kafka 용 Amazon Managed Streaming (아마존 MSK). 생산 라인의 센서 데이터를 저장하기 위해 Krones는 Kinesis를 선택했습니다. Kinesis는 모든 규모에서 낮은 지연 시간으로 작동하는 서버리스 스트리밍 데이터 서비스입니다. Kinesis 데이터 스트림 내의 샤드는 고유하게 식별되는 데이터 레코드 시퀀스이며, 여기서 스트림은 하나 이상의 샤드로 구성됩니다. 각 샤드에는 2MB/s의 읽기 용량과 1MB/s의 쓰기 용량이 있습니다(최대 1,000개 레코드/s). 이러한 제한에 도달하지 않으려면 데이터를 샤드 간에 최대한 균등하게 배포해야 합니다. Kinesis로 전송되는 모든 레코드에는 데이터를 샤드로 그룹화하는 데 사용되는 파티션 키가 있습니다. 따라서 로드를 균등하게 분산하려면 많은 수의 파티션 키가 필요합니다. AWS IoT Greengrass에서 실행되는 스트림 관리자는 무작위 파티션 키 할당을 지원합니다. 즉, 모든 레코드가 무작위 샤드로 끝나고 로드가 균등하게 분산됩니다. 무작위 파티션 키 할당의 단점은 Kinesis에서 레코드가 순서대로 저장되지 않는다는 것입니다. 워터마크에 대해 이야기하는 다음 섹션에서 이 문제를 해결하는 방법을 설명합니다.

워터 마크

A 워터 마크 데이터 스트림에서 이벤트 시간의 진행 상황을 추적하고 측정하는 데 사용되는 메커니즘입니다. 이벤트 시간은 소스에서 이벤트가 생성된 시점의 타임스탬프입니다. 워터마크는 스트림 처리 애플리케이션의 적시 진행을 나타내므로 타임스탬프가 이전이거나 동일한 모든 이벤트는 처리된 것으로 간주됩니다. 이 정보는 Flink가 이벤트 시간을 앞당기고 창 평가와 같은 관련 계산을 트리거하는 데 필수적입니다. 이벤트 시간과 워터마크 사이에 허용되는 지연을 구성하여 기간 완료를 고려하고 워터마크를 진행하기 전에 지연 데이터를 기다리는 시간을 결정할 수 있습니다.

Krones는 전 세계에 시스템을 보유하고 있으며 연결 끊김이나 기타 네트워크 제약으로 인해 늦게 도착하는 고객을 처리해야 했습니다. 그들은 지각을 모니터링하고 기본 Flink 지연 처리를 이 측정항목에서 확인한 최대값으로 설정하는 것으로 시작했습니다. 그들은 에지 장치의 시간 동기화 문제를 경험했으며 이로 인해 보다 정교한 워터마킹 방법을 사용하게 되었습니다. 그들은 모든 발신자에 대해 전역 워터마크를 구축하고 가장 낮은 값을 워터마크로 사용했습니다. 타임스탬프는 들어오는 모든 이벤트에 대해 HashMap에 저장됩니다. 워터마크가 주기적으로 방출될 때 이 HashMap의 가장 작은 값이 사용됩니다. 데이터 누락으로 인한 워터마크 지연을 방지하기 위해 그들은 idleTimeOut 특정 임계값보다 오래된 타임스탬프를 무시하는 매개변수입니다. 이로 인해 대기 시간이 늘어나지만 강력한 데이터 일관성이 제공됩니다.

public class BucketWatermarkGenerator implements WatermarkGenerator<DataPointEvent> {
private HashMap <String, WatermarkAndTimestamp> lastTimestamps;
private Long idleTimeOut;
private long maxOutOfOrderness;
}

스트림 처리

데이터가 센서에서 수집되어 Kinesis로 수집된 후에는 규칙 엔진에 의해 평가되어야 합니다. 이 시스템의 규칙은 단일 지표(예: 온도) 또는 지표 모음의 상태를 나타냅니다. 측정항목을 해석하려면 상태 저장 계산인 두 개 이상의 데이터 포인트가 사용됩니다. 이 섹션에서는 Apache Flink의 키 입력 상태 및 브로드캐스트 상태와 이러한 상태가 Krones 규칙 엔진을 구축하는 데 어떻게 사용되는지 자세히 알아봅니다.

제어 스트림 및 브로드캐스트 상태 패턴

아파치 플링크에서는 상태 시간과 운영 전반에 걸쳐 지속적으로 정보를 저장하고 관리하는 시스템의 능력을 말하며, 상태 저장 계산을 지원하여 스트리밍 데이터를 처리할 수 있습니다.

XNUMXD덴탈의 브로드캐스트 상태 패턴 연산자의 모든 병렬 인스턴스에 상태를 배포할 수 있습니다. 따라서 모든 연산자는 동일한 상태를 가지며 이 동일한 상태를 사용하여 데이터를 처리할 수 있습니다. 이 읽기 전용 데이터는 제어 스트림을 사용하여 수집할 수 있습니다. 제어 스트림은 일반 데이터 스트림이지만 일반적으로 데이터 속도가 훨씬 낮습니다. 이 패턴을 사용하면 모든 연산자의 상태를 동적으로 업데이트할 수 있으므로 사용자는 재배포할 필요 없이 애플리케이션의 상태와 동작을 변경할 수 있습니다. 보다 정확하게는 상태 분포가 제어 스트림을 사용하여 수행됩니다. 제어 스트림에 새 레코드를 추가하면 모든 운영자가 이 업데이트를 수신하고 새 메시지 처리를 위해 새 상태를 사용하게 됩니다.

이를 통해 Krones 애플리케이션 사용자는 Flink 애플리케이션을 다시 시작하지 않고도 새로운 규칙을 Flink 애플리케이션에 수집할 수 있습니다. 이를 통해 가동 중지 시간을 방지하고 실시간으로 변경 사항이 발생함에 따라 뛰어난 사용자 경험을 제공합니다. 규칙은 프로세스 편차를 감지하기 위해 시나리오를 다룹니다. 때로는 머신 데이터가 언뜻 보기에 해석하기 쉽지 않은 경우도 있습니다. 온도 센서가 높은 값을 보내는 경우 이는 오류를 나타낼 수도 있지만 지속적인 유지 관리 절차의 영향일 수도 있습니다. 메트릭을 컨텍스트에 배치하고 일부 값을 필터링하는 것이 중요합니다. 이는 다음과 같은 개념에 의해 달성됩니다. 그룹화.

측정항목 그룹화

데이터와 지표를 그룹화하면 들어오는 데이터의 관련성을 정의하고 정확한 결과를 생성할 수 있습니다. 다음 그림의 예를 살펴보겠습니다.

측정항목 그룹화

1단계에서는 두 개의 조건 그룹을 정의합니다. 그룹 1은 기계 상태와 라인을 통과하는 제품을 수집합니다. 그룹 2는 온도 및 압력 센서의 값을 사용합니다. 조건 그룹은 수신하는 값에 따라 다른 상태를 가질 수 있습니다. 이 예에서 그룹 1은 기계가 작동 중이라는 데이터를 수신하고 XNUMX리터 병이 제품으로 선택되었습니다. 이것은 이 그룹에 상태를 제공합니다 ACTIVE. 그룹 2에는 온도와 압력에 대한 측정항목이 있습니다. 두 지표 모두 5분 넘게 임계값을 초과했습니다. 이로 인해 그룹 2는 다음과 같은 상태가 됩니다. WARNING 상태. 이는 그룹 1이 모든 것이 괜찮다고 보고하고 그룹 2는 그렇지 않다고 보고한다는 의미입니다. 2단계에서는 그룹에 가중치가 추가됩니다. 그룹이 상충되는 정보를 보고할 수 있으므로 이는 일부 상황에서 필요합니다. 이 시나리오에서는 그룹 1이 보고합니다. ACTIVE 및 그룹 2 보고서 WARNING, 따라서 시스템에서는 회선의 상태가 무엇인지 명확하지 않습니다. 가중치를 추가한 후 3단계에서 볼 수 있듯이 상태의 순위를 매길 수 있습니다. 마지막으로 4단계에서 볼 수 있듯이 가장 높은 순위의 상태가 승리한 상태로 선택됩니다.

규칙을 평가하고 최종 기계 상태를 정의한 후 결과가 추가로 처리됩니다. 수행되는 작업은 규칙 구성에 따라 다릅니다. 이는 라인 운영자에게 자재 보충, 유지 관리 수행 또는 대시보드의 시각적 업데이트에 대한 알림일 수 있습니다. 측정항목과 규칙을 평가하고 결과에 따라 조치를 취하는 시스템의 이 부분을 규칙 엔진.

규칙 엔진 확장

사용자가 자신의 규칙을 작성할 수 있도록 함으로써 규칙 엔진은 평가해야 하는 많은 수의 규칙을 가질 수 있으며 일부 규칙은 다른 규칙과 동일한 센서 데이터를 사용할 수 있습니다. Flink는 수평적으로 매우 잘 확장되는 분산 시스템입니다. 데이터 스트림을 여러 작업에 배포하려면 다음을 사용할 수 있습니다. keyBy() 방법. 이를 통해 데이터 스트림을 논리적인 방식으로 분할하고 데이터의 일부를 다른 작업 관리자로 보낼 수 있습니다. 이는 균등하게 분산된 로드를 얻을 수 있도록 임의의 키를 선택하여 수행되는 경우가 많습니다. 이 경우 Krones는 다음을 추가했습니다. ruleId 데이터 포인트에 연결하여 키로 사용했습니다. 그렇지 않으면 필요한 데이터 포인트가 다른 작업에 의해 처리됩니다. 키가 지정된 데이터 스트림은 일반 변수처럼 모든 규칙에서 사용할 수 있습니다.

목적지

규칙의 상태가 변경되면 정보는 Kinesis 스트림으로 전송된 다음 다음을 통해 전송됩니다. 아마존 이벤트 브리지 소비자에게. 소비자 중 한 명이 생산 라인으로 전송되는 이벤트로부터 알림을 생성하고 직원에게 조치를 취하도록 경고합니다. 규칙 상태 변경을 분석할 수 있도록 다른 서비스는 데이터를 아마존 DynamoDB 빠른 액세스를 위한 테이블과 추가 보고를 위해 장기 기록을 Amazon S3로 오프로드하기 위한 TTL이 마련되어 있습니다.

결론

이 게시물에서는 Krones가 어떻게 AWS에서 실시간 생산 라인 모니터링 시스템을 구축했는지 보여주었습니다. Apache Flink용 관리형 서비스를 통해 Krones 팀은 인프라가 아닌 애플리케이션 개발에 집중하여 빠르게 시작할 수 있었습니다. Flink의 실시간 기능을 통해 Krones는 기계 가동 중지 시간을 10% 줄이고 효율성을 최대 5% 높일 수 있었습니다.

자신만의 스트리밍 애플리케이션을 구축하려면 다음에서 사용 가능한 샘플을 확인하세요. GitHub 저장소. 사용자 정의 커넥터를 사용하여 Flink 애플리케이션을 확장하려면 다음을 참조하세요. Apache Flink를 사용하여 커넥터 구축을 더욱 쉽게 만들기: 비동기 싱크 소개. 비동기 싱크는 Apache Flink 버전 1.15.1 이상에서 사용할 수 있습니다.

저자에 관하여

플로리안 마이어 AWS의 수석 솔루션 아키텍트이자 데이터 스트리밍 전문가입니다. 그는 AWS 클라우드 서비스를 사용하여 비즈니스 과제를 해결함으로써 유럽 고객의 성공과 혁신을 돕는 기술자입니다. 솔루션 설계자로 일하는 것 외에도 Florian은 열정적인 등산가이며 유럽 전역에서 가장 높은 산을 등반했습니다.

에밀 디틀 그는 Apache Flink 및 마이크로서비스 분야의 핵심 분야인 데이터 엔지니어링을 전문으로 하는 Krones의 수석 기술 책임자입니다. 그의 업무에는 미션 크리티컬 소프트웨어의 개발 및 유지 관리가 포함되는 경우가 많습니다. 직업 생활 외에도 그는 가족과 함께 좋은 시간을 보내는 것을 매우 중요하게 생각합니다.

사이먼 페이어 스위스에 본사를 둔 AWS의 솔루션 아키텍트입니다. 그는 실용적인 실천가이며 AWS 클라우드 서비스를 사용하여 기술과 사람을 연결하는 데 열정을 갖고 있습니다. 그가 특별히 집중하는 분야는 데이터 스트리밍과 자동화입니다. 일 외에도 Simon은 가족과 야외 활동, 산에서의 하이킹을 즐깁니다.

spot_img

최신 인텔리전스

spot_img

저작권 @ 2024 Plato Technologies Inc.