본문으로 건너뛰기

Grafana로 시각화와 트렌딩

📍 현재 위치: 3부, 우리가 그동안 저장해 온 맥락화된(contextualized) 배치(batch) 데이터가 마침내 운영자가 지켜보고 엔지니어가 신뢰하는 하나의 그림이 되는 계층입니다.

쉽게 말하면

여러분의 히스토리언(historian)과 배치 데이터베이스를, 숫자들이 완벽하게 정리된 거대한 도서관이라고 생각해 보세요. Grafana는 그 도서관의 열람실입니다. 단 한 권의 책도 직접 소유하지 않습니다. 올바른 서가로 걸어가, 여러분이 요청한 행(row)들을 꺼내 와, 한눈에 읽을 수 있는 트렌드(trend)로 펼쳐 보일 뿐입니다. 중요한 부분은 대부분의 사람들이 잊는 바로 그것입니다. 모든 차트는 그저 저장된 질문(saved question) 이라는 점입니다. 데이터가 바뀌면 차트도 바뀝니다. 바로 그렇기 때문에 Grafana 트렌드는 증거가 될 수 있지만 그 스크린샷은 증거가 될 수 없습니다. 스크린샷은 책이 아니라 열람실을 찍은 사진이기 때문입니다.

이 장에서 다루는 내용​

우리는 이미 들여다볼 가치가 있는 데이터를 갖고 있습니다. TimescaleDB 히스토리언 안의 14일 유가식(fed-batch) CHO 추적선(trace), PostgreSQL 안의 ISA-88/95 배치 모델, 그리고 그 둘을 조인(join)하는 맥락화 뷰(view)입니다. 이 장에서는 이 모든 것 위에 오픈소스 대시보드 계층을 세웁니다.

우리는 (1) 공유 compose.yaml의 고정된 한 줄에서 Grafana를 띄우고, (2) 그것의 데이터 소스(data source)와 대시보드를 클릭으로 짜 맞추는 대신 코드로(as code) 프로비저닝(provisioning)하고, (3) 같은 맥락화 데이터 위에 운영자 뷰(operator view)와 더 조밀한 엔지니어 뷰(engineer view)를 만들고, (4) 알림 규칙(alert rule) 하나를 연결하고, (5) Grafana를 규제 공장에 어른스러운(grown-up) 선택으로 만드는 두 가지 — 그것의 AGPLv3 라이선스 조항과, 트렌드는 검증된 데이터로부터 재현 가능할 때에만 증거가 된다는 엄격한 규칙 — 과 정면으로 마주합니다. Grafana는 AVEVA PI Vision 같은 상업용 공정 시각화 제품의 오픈소스 대응물이며, 맥락화된 실시간 데이터 위의 운영자/엔지니어 대시보드는 단일클론항체(monoclonal antibody, mAb) 라인을 실제로 운전하는 데 핵심입니다 [1].

Grafana는 이미 스택에 들어 있다​

이 책에서 여러분은 Grafana를 설치하지 않습니다. 그것은 공유 플랫폼 스택에서 단 한 번 선언되었으며, Postgres, 브로커(broker), 시뮬레이터(simulator)와 나란히 core 프로파일과 함께 올라옵니다. 다음은 examples/platform/compose/compose.yaml에서 가져온 실제 서비스입니다.

# examples/platform/compose/compose.yaml
  grafana:
    image: grafana/grafana-oss:11.4.0
    profiles: ["core"]
    <<: *restart
    ports: ["3000:3000"]
    environment:
      GF_SECURITY_ADMIN_PASSWORD: ${GRAFANA_PASSWORD:-admin}
      GF_USERS_ALLOW_SIGN_UP: "false"
    volumes:
      - ../dashboards/provisioning:/etc/grafana/provisioning:ro
      - grafana:/var/lib/grafana
    depends_on:
      postgres:
        condition: service_healthy

이 블록은 천천히 읽으세요. 거의 모든 줄이 의도적인, GxP 색채를 띤 선택이기 때문입니다.

  • grafana/grafana-oss:11.4.0 — 태그로 고정되어 있으며, 다이제스트(digest)로의 고정이 의도된 다음 단계입니다(compose.yaml 헤더는 이미지들이 versions.lock에서 다이제스트로 잠기도록 의도되었음을 명시합니다. 그 잠금 파일은 계획된 메커니즘이지만 아직 이 저장소(repo)에 커밋되지는 않았습니다). 이것은 Grafana Enterprise나 Grafana Cloud가 아니라 오픈소스 배포판입니다. 우리는 고정된 11.4.x를 사용하여 docker compose pull이 검증된 대시보드 아래에서 버전을 조용히 갈아치우는 일이 결코 일어나지 않도록 합니다.
  • profiles: ["core"] — Grafana는 항상 켜져 있는 기반입니다. compose 헤더에 따르면 core 프로파일은 저장/시각화 장들(14, 1315장)을 포괄하며, 포착·시맨틱·분석 장들도 모두 이를 통해 읽어 들입니다.
  • GF_USERS_ALLOW_SIGN_UP: "false" — 익명 자가 등록(self-registration)이 꺼져 있습니다. 규제 맥락에서는 모든 행위가 이름이 부여되고 프로비저닝된 신원에 귀속되기를 바라지, 즉석에서 만든 계정에 귀속되기를 바라지 않습니다.
  • ../dashboards/provisioning:/etc/grafana/provisioning:ro — 전체 프로비저닝 트리가 읽기 전용(read-only) 으로 마운트됩니다. Grafana는 시작 시 버전 관리되는 파일들에서 데이터 소스와 대시보드를 읽으며, 그것들에 되써넣을 수 없습니다.
  • depends_on: postgres … service_healthy — Grafana는 히스토리언과 배치 모델을 모두 담고 있는 데이터베이스가 헬스체크(healthcheck)를 통과하기 전까지는 아예 시작조차 하지 않습니다. 아직 준비되지 않은 데이터베이스를 가리키는 대시보드란 없습니다.

이를 띄우고 http://localhost:3000에서 접속합니다.

docker compose --profile core up -d

그 태그에 관해 이 책이 여러분에게 빚진 한 가지 메모입니다. 플랫폼의 사양 서술(spec narrative)은 더 새로운 Grafana를 겨냥하지만, 테스트된 compose 파일은 11.4.0을 고정하므로, 그것이 저장소가 실제로 돌리는 것이자 이 장이 인쇄하는 것입니다. 숫자 자체보다 중요한 것은 규율입니다. 다이제스트 수준 잠금(compose 헤더가 가리키는 versions.lock)의 목표는, 그것이 기록하는 것이 CI가 받아 오는 것, 라이선스 인벤토리가 기록하는 것, 공급자 등록부(supplier register)가 검증하는 것과 정확히 일치하도록 하는 것입니다. 가동 중인 스택과 그 문서가 서로 어긋나도록 내버려 두어서는 안 됩니다.

클릭이 아니라 코드로 만드는 대시보드​

규제 대상 대시보드를 잃는 가장 빠른 방법은, 브라우저에서 손으로 아름답게 만들어 놓고 어디에도 저장하지 않는 것입니다. Grafana의 답은 프로비저닝 입니다. 데이터 소스와 대시보드를 UI에서 클릭으로 짜 맞추는 대신, 시작 시 로드되는 버전 관리된 YAML/JSON 파일로 정의하는 것입니다 [2]. 위 compose 서비스가 읽기 전용으로 마운트하고 저장소에 커밋한 그 provisioning/ 디렉터리는 고정된 형태를 갖습니다.

examples/platform/dashboards/provisioning/
├── datasources/
│   └── timescaledb.yaml          # how Grafana reaches Postgres/TimescaleDB
├── dashboards/
│   ├── dashboards.yaml           # tells Grafana where to find dashboard JSON
│   └── json/
│       └── br101-batch-overlay.json   # the engineer/operator dashboard
└── alerting/
    └── batch-alerts.yaml          # alert rules + contact points as code

데이터 소스는 한 파일, datasources/timescaledb.yaml입니다(히스토리언과 배치 모델은 동일한 PostgreSQL 인스턴스이므로, 하나의 데이터 소스가 둘 다를 담당합니다).

# examples/platform/dashboards/provisioning/datasources/timescaledb.yaml
apiVersion: 1
datasources:
  - name: TimescaleDB
    uid: timescaledb            # stable uid so dashboard JSON references survive
    type: postgres
    url: postgres:5432          # the compose service hostname, not localhost
    user: ${POSTGRES_USER}
    jsonData:
      database: ${POSTGRES_DB}
      sslmode: disable          # fine inside the compose network; TLS is Ch 25
      timescaledb: true         # enables Grafana's TimescaleDB-aware $__timeGroupAlias / time_bucket handling
    secureJsonData:
      password: ${POSTGRES_PASSWORD}
    editable: false             # provisioned, read-only: changes go through Git

두 가지 세부가 제 몫을 합니다. uid: timescaledb는 안정적인(stable) 식별자입니다. 대시보드 JSON은 자동 생성된 식별자가 아니라 이 uid를 참조하므로, 노트북에서 내보낸 대시보드가 서버에서 변경 없이 로드됩니다. 그리고 editable: false는 운영자가 데이터 소스를 다른 데이터베이스로 조용히 다시 가리키게 할 수 없다는 뜻입니다. 그 변경은 파일을 거쳐야 하고, 그 파일은 Git 리뷰를 거칩니다.

대시보드 제공자(provider) 파일은 단지 Grafana를 대시보드 JSON 폴더로 가리킵니다.

# examples/platform/dashboards/provisioning/dashboards/dashboards.yaml
apiVersion: 1
providers:
  - name: bioproc-dashboards
    type: file
    allowUiUpdates: false       # the UI cannot overwrite the file-of-record
    options:
      path: /etc/grafana/provisioning/dashboards/json
      foldersFromFilesStructure: true

allowUiUpdates: false는 규제적 태세입니다. 누군가 브라우저에서 패널(panel)을 탐색하고 손볼 수는 있지만, 디스크 위의 파일 — 버전 관리 안에 있는 그 파일 — 이 진실의 기록(record of truth)으로 남습니다. 실제 공장에서 Grafana가 권장하는 경로는 한 걸음 더 나아갑니다. 이 파일들을 CI/CD와 Git Sync를 통해 관리하여, 모든 대시보드 변경이 애플리케이션 코드와 똑같이 리뷰되고, 버전이 매겨지고, 재현 가능하게 배포되도록 하는 것입니다 [3].

대시보드는 JSON 문서이며, 그 안의 패널 은 우리 히스토리언에 대한 저장된 SQL 쿼리입니다. 다음은 커밋된 dashboards/json/br101-batch-overlay.json 패널의 핵심 — 매끄러운 렌더링을 위해 시간으로 버킷화(time-bucketed)된, 바이오리액터 온도 트렌드를 그리는 쿼리입니다.

{
  "title": "BR101 Temperature (PV vs setpoint)",
  "type": "timeseries",
  "datasource": { "type": "postgres", "uid": "timescaledb" },
  "fieldConfig": { "defaults": { "unit": "celsius" } },
  "targets": [
    {
      "rawSql": "SELECT time_bucket('1 minute', ts) AS time, avg(value) AS \"Temp PV\" FROM ts.sensor_reading WHERE tag = 'BR101.Temp.PV' AND batch_id = '$batch' AND $__timeFilter(ts) GROUP BY 1 ORDER BY 1",
      "format": "time_series"
    }
  ]
}

이 패널은 하나의 질문에 불과합니다. 선택된 배치에 대해, 온도 태그를 분 단위로 버킷화하여 평균을 내라. $batch는 운영자가 드롭다운에서 고르는 대시보드 변수이고, $__timeFilter(ts)는 보이는 시간 범위를 주입하는 Grafana 매크로(macro)입니다. 일주일 뒤 같은 히스토리언에 이를 겨냥하면 같은 선이 나옵니다. 그 선은 데이터로부터 계산되는 것이지, 그 위에 붙여 놓은 것이 아니기 때문입니다.

두 청중, 하나의 데이터 집합​

같은 맥락화 데이터가 아주 다른 두 독자를 섬기며, 좋은 관행은 그들에게 빽빽하게 절충한 하나가 아니라 두 개의 대시보드를 주는 것입니다.

운영자 뷰 는 차분하고 결정 지향적입니다. 큼직한 스탯(stat) 패널 몇 개(현재 역가(titer), 생존 세포 밀도(viable-cell density), DO, pH), 설정값(setpoint)에 대비한 온도 트렌드, 그리고 "밴드 안 / 밴드 밖(in band / out of band)"을 분명히 나타내는 빨강/초록 상태입니다. 위의 쿼리는 이미 각 값에 batch_id를 태그하므로, 운영자의 드롭다운은 지금 현장에 있는 배치로 모든 것을 필터링합니다.

엔지니어 뷰 는 조밀하고 탐사적입니다. 모든 태그가 겹쳐지고, 시뮬레이터가 의도적으로 심은 7일째 0.5 °C 일탈(excursion), 배치 모델의 볼루스 피드(bolus-feed) 이벤트가 주석(annotation)으로 그려지고, events.operation_event에서 끌어온 Protein A 크로마토그램(chromatogram) 단계(phase)가 표시됩니다. 두 대시보드 모두 맥락화된 계층 — 히스토리언이 ISA-88/95 배치 모델에 조인된 것 — 을 읽기 때문에, 엔지니어는 "역가"와 "피드 이벤트"를 겹쳐 놓고 원인을 결과 옆에서 볼 수 있습니다.

다음은 우리 패널이 실제로 그리는 종류의 행으로, 히스토리언 하이퍼테이블(hypertable)에서 바로 가져온 것입니다(롱 포맷(long format), 타임스탬프마다 태그당 한 행).

        ts         |       tag       | value | unit | quality |   batch_id
-------------------+-----------------+-------+------+---------+---------------
 2026-05-08 07:00  | BR101.Temp.PV   | 37.01 | degC |     192 | BATCH-2026-001
 2026-05-08 07:00  | BR101.pH.PV     |  7.05 | pH   |     192 | BATCH-2026-001
 2026-05-08 07:00  | BR101.DO.PV     | 48.2  | %sat |     192 | BATCH-2026-001
 2026-05-08 07:00  | BR101.Titer.PV  |  2.41 | g/L  |     192 | BATCH-2026-001
 2026-05-08 07:01  | BR101.DO.PV     | 47.9  | %sat |      64 | BATCH-2026-001

저 quality 열은 장식이 아닙니다. 그것은 엣지(edge)에서 포착된 OPC UA 상태 코드(status code)를 담고 있으며, 히스토리언 DDL(examples/platform/db/20-historian.sql)은 그 인코딩을 주석에 고정합니다. 192 = Good, 64 = Uncertain, 0 = Bad 입니다. 위 행들 중 넷은 Good (192)로 도착했고, 마지막 DO 샘플은 Uncertain (64)로 돌아왔습니다. 따라서 패널은 Good으로 도착하지 않은 값을 회색 처리하거나 표시할 수 있습니다. 대시보드는 신뢰할 수 없는 점을 마치 건전한 것처럼 조용히 트렌딩하지 않습니다.

버전 관리되는 YAML과 JSON 프로비저닝 파일이 Grafana에 읽기 전용으로 마운트되고, Grafana가 결합된 PostgreSQL과 TimescaleDB 히스토리언에 SQL을 발행하며, 같은 맥락화 데이터가 차분한 운영자 대시보드, 조밀한 엔지니어 대시보드, 그리고 연락 지점으로 라우팅되는 알림으로 렌더링되는 모습을 보여주는 계층 다이어그램. Grafana는 어떤 데이터도 소유하지 않습니다. 코드로 프로비저닝된 대시보드와 알림이 필요할 때마다 맥락화 히스토리언을 쿼리하므로, 모든 트렌드는 저장된 그림이 아니라 재현 가능한 질문입니다. Original diagram by the authors, created with AI assistance.

알림: 여러분을 호출하는 대시보드​

새벽 3시에 아무도 보지 않는 트렌드는 그다지 쓸모가 없습니다. Grafana의 통합 알림(unified alerting)은 하나 이상의 데이터 소스에 걸쳐 규칙을 평가하고, 연락 지점(contact point) 과 알림 정책(notification policy) 을 통해 알림을 라우팅합니다 — PI Vision/Notifications의 오픈소스 대응물입니다 [4]. 규칙도 대시보드처럼 코드로 프로비저닝됩니다. 심어진 7일째 온도 일탈에 대한, 커밋된 alerting/batch-alerts.yaml 규칙은 다음과 같습니다.

# examples/platform/dashboards/provisioning/alerting/batch-alerts.yaml
apiVersion: 1
groups:
  - orgId: 1
    name: bioreactor
    folder: BR101
    interval: 1m
    rules:
      - title: BR101 temperature out of band
        condition: C
        data:
          - refId: A                 # query the historian
            datasourceUid: timescaledb
            model:
              rawSql: >
                SELECT $__timeGroupAlias(ts,'1m'), avg(value) AS temp
                FROM ts.sensor_reading
                WHERE tag='BR101.Temp.PV' AND $__timeFilter(ts)
                GROUP BY 1 ORDER BY 1
          - refId: C                 # threshold: outside 36.5-37.5 degC
            type: threshold
            model:
              conditions:
                - evaluator: { type: outside_range, params: [36.5, 37.5] }
        for: 5m                      # must persist 5 min to avoid flapping
        labels: { severity: warning }

for: 5m 절은 유용한 알림과 성가신 알림을 가르는 차이입니다. 잡음이 섞인 단일 샘플 하나는 누구도 호출하지 않지만, 진짜 5분짜리 드리프트(drift)는 호출합니다. 이 알림이 아닌 것에 주목하세요. 그것은 저장된 판단(stored judgment)이 아닙니다. 그것은 쿼리 더하기 임계값(threshold)이며, 둘 다 Git에 있고, 둘 다 다시 평가할 수 있습니다. 나중에 일탈 조사(deviation investigation)가 "무엇이, 왜 발화했는가"를 묻는다면, 답은 기억이 아니라 규칙 정의와 그것이 실행된 히스토리언 행들입니다.

왜 중요한가​

이 장의 가장 깊은 발상은 한 줄입니다. 트렌드는 검증된 데이터로부터 재현 가능할 때에만 증거이고, 스크린샷은 기록이 아니다. Part 11은 시스템이 정확하고 완전한 기록 사본을 생성하고 타임스탬프가 찍힌 감사 추적(audit trail)을 유지하기를 요구합니다(구체적으로 11.10(b)와 11.10(e)) [5]. EU Annex 11은 전산화 시스템의 인쇄물과 트렌드가 명확해야 하며, 어떤 보고서든 그 바탕이 되는 데이터가 시스템까지 추적 가능해야 한다고 요구합니다 [6]. FDA의 데이터 무결성 Q&A와 MHRA의 ALCOA+ 지침은 둘 다 무결성 측면에서 같은 요점을 짚습니다. GMP 결정은 일시적인 디스플레이가 아니라, 귀속 가능하고(attributable), 원본이거나 인증 사본이며(original-or-certified-copy), 재구성 가능한(reconstructable) 기록에 근거해야 한다는 것입니다 [7][8].

Grafana는 올바르게 사용한다면 이에 아름답게 들어맞습니다. 모든 패널이 히스토리언에 대한 저장된 쿼리이지 — 구워 넣은 이미지가 아니므로 — 접근 권한이 있는 누구라도 필요할 때마다 그것을 다시 실행하여 동일한 트렌드를 재생성할 수 있습니다. 그것이 실무에서 "데이터로부터 재현 가능"이 뜻하는 바입니다. 실패 양상은 PNG를 보고서에 붙여 넣는 문화입니다. 그 그림이 그것을 만들어낸 행들과의 연결을 모두 잃은 채로 살아남는 것입니다. 코드로 만드는 대시보드는 좋은 경로를 강화합니다. 출하 트렌드를 그린 정확한 그 쿼리가, 여러분이 diff하고, 리뷰하고, 재현할 수 있는 버전 관리된 산출물(versioned artifact)이 됩니다.

실제 현장에서는​

맥락화된 실시간 공정 데이터 위의 운영자 및 엔지니어 대시보드는 현대적 mAb 라인에서 있으면 좋은 것이 아니라, 공정이 운전되고 제어되는 방식 그 자체이며, 점점 더 소프트 센서(soft sensor)와 다변량 분석(multivariate analytics)과 나란히 갑니다 [1]. 대부분의 공장이 아는 상업용 기준점은 PI System 히스토리언 위에 자리한 AVEVA PI Vision입니다. Grafana는 신뢰할 만한 오픈소스 대응물이며, 파일럿 규모 — NIIMBL의 SABRE 시설(2024년 4월 착공한 NIIMBL / 델라웨어 대학교(University of Delaware)의 파일럿 규모 cGMP — current good manufacturing practice — 시설) 같은 곳 — 에서는 오픈 히스토리언 위의 오픈 대시보드 계층이 전적으로 합리적인 구축입니다.

이제 정직한 부분입니다. "노트북에서 멋지게 돌아간다"와 "GMP 출하 결정을 짊어진다" 사이를 가르는 두 가지 한계가 있습니다.

AGPLv3 조항. 2021년 Grafana Labs는 Grafana의 핵심(그리고 Loki와 Tempo)을 Apache 2.0에서 AGPLv3로 재라이선싱했습니다 [9]. AGPLv3는 Section 13, 즉 원격 네트워크 상호작용(remote network interaction) 조항을 더합니다. 여러분이 Grafana의 소스를 수정 한 뒤 그 수정된 버전을 네트워크를 통해 사용자에게 제공한다면, 그에 상응하는 수정된 소스를 그 원격 사용자들에게 제공해야 합니다 [10]. 압도적 대다수의 공장에 이것은 아무것도 바꾸지 않습니다. 수정하지 않은 공식 이미지를 자사 운영자들을 위해 내부적으로 돌리는 것은 어떤 소스 공개 의무도 부과하지 않습니다. 함정은 더 좁습니다. Grafana 자체를 포크(fork)하여 패치한 뒤 그 포크를 서비스로 노출하거나, 그것을 묶어 재배포하는 경우입니다. 이 책은 안전한 쪽에 머물기 위해 정확히 수정하지 않은 grafana-oss 이미지를 제공하고, AGPLv3를 라이선스 인벤토리에 표시하여 그 의무가 감사 중의 깜짝 사건이 아니라 문서화된 결정이 되도록 합니다.

검증의 마지막 한 마장(last mile). Grafana는 상자에서 꺼내자마자 21 CFR Part 11 / Annex 11을 준수하지 않습니다 — 어떤 OSS 도구도 그렇지 않으며, 이는 스택 전체에 해당합니다. 준수는 다운로드가 아니라 검증된 시스템 더하기 절차(validated system plus procedures) 의 속성입니다. Grafana OSS는 코드로 만드는 대시보드, 프로비저닝된 신원, 그리고 데이터로부터 재현 가능한 쿼리를 줍니다 — 여기서 순수 오픈 소스가 진정으로 전달할 수 있는 그 약 80%입니다. GxP 마지막 한 마장에서 하이브리드 현실이 물어뜯습니다. Grafana OSS에는 네이티브 Part 11 전자 서명(e-signature)이 없고, 그것의 더 풍부한 접근 제어(세분화된 RBAC, SSO/SAML, 리포팅, 데이터 소스 권한)는 OSS 빌드가 아니라 Grafana Enterprise / Cloud에 있습니다. 규제 대상 배포는 Grafana 주위에 둘러친 검증된 시스템으로 그 간극을 메웁니다 — 신원 공급자(identity provider), 데이터베이스 안의 감사 추적, 프로비저닝 저장소에 대한 변경 관리(change control), 그리고 출하 트렌드는 저장된 이미지로 신뢰하는 일이 결코 없이 히스토리언으로부터 재생성한다고 명시하는 SOP입니다. 대시보드는 오픈 소스이고, 신뢰는 여러분이 그 주위에 세우는 시스템에서 옵니다.

핵심 용어​

  • 코드로 만드는 대시보드(dashboard-as-code) — Grafana 데이터 소스, 대시보드, 알림을 UI에서 클릭하는 대신 시작 시 로드되는 버전 관리된 YAML/JSON 파일로 정의하는 것.
  • 프로비저닝(provisioning) — 부팅 시 마운트된 디렉터리에서 그 파일들을 읽는 Grafana 메커니즘. 여기서는 UI가 진실의 기록을 덮어쓸 수 없도록 읽기 전용으로 마운트됨.
  • 데이터 소스(data source) — Grafana가 필요할 때마다 쿼리하는 구성된 연결(여기서는 uid: timescaledb). Grafana는 데이터 자체를 전혀 저장하지 않음.
  • 패널 / 타깃(panel / target) — 단일 시각화와 그것을 먹이는 SQL 쿼리. 트렌드가 저장된 그림이 아니라 재현 가능한 질문 인 이유.
  • 연락 지점 / 알림 정책(contact point / notification policy) — 규칙이 발화할 때 Grafana가 어디로 어떻게 알림을 보내는지.
  • AGPLv3 Section 13 — 수정된 Grafana를 네트워크를 통해 제공할 때 소스 공개를 요구하는 네트워크/원격 상호작용 조항.
  • PI Vision — AVEVA의 상업용 공정 시각화 제품. Grafana는 이 장이 구축하는 그 오픈소스 대응물.
  • 데이터로부터 재현 가능(reproducible-from-data) — 증거로 쓰이는 트렌드가 검증된 기록으로부터 재생성 가능해야 한다는 규제 규칙. 스크린샷은 그러지 못함.

다음 이야기​

우리는 이제 데이터를 볼 수 있고 그 그림을 신뢰할 수 있습니다. 하지만 Grafana, 히스토리언, 배치 모델은 여전히 "같은 것"을 조금씩 다른 방언으로 말합니다. 다음 장 시맨틱과 디지털 스레드: 온톨로지와 지식 그래프(Semantics & the Digital Thread: Ontologies and a Knowledge Graph) 는 공장 전체에 하나의 공유된 의미를 부여합니다 — 장비, 물질, 레시피, 결과를 온톨로지(ontology)로 모델링하고 이를 RDF/SPARQL 지식 그래프(knowledge graph)로 엮어, 단일한 핵심 품질 속성(critical quality attribute)을 업스트림, 다운스트림, QC에 걸쳐 하나의 쿼리로 추적할 수 있게 합니다.