생산 바이오리액터 모델링: 하나의 공정, 그 단계들, 그리고 그 매개변수들

📍 현재 위치: 3부 · 모델링된 상류(upstream) — 11장. 종균 배양(seed train)이 충분한 세포를 넘겨주었습니다. 이제 그 세포들이 생산 바이오리액터로 들어가, 분자가 실제로 만들어지는 곳 — 그리고 1부에서 다룬 연속체(continuant)/발생체(occurrent) 구분이 더 이상 이론이 아니라 이 책에서 가장 중대한 모델링 선택이 되는 곳 — 으로 향합니다.

이곳은 상류 전체가 가리키는 장입니다. SEED-001에서 온 세포가 큰 교반 탱크에 접종되고, 두어 주에 걸쳐 자란 뒤 항체 생산으로 전환되며, 한 무리의 탐침이 몇 초마다 이를 감시합니다. 이곳은 또한 부주의한 모델이 조용히 무너지는 곳이기도 합니다. 1부가 서로 다르다고 못박은 세 가지 — 용기(vessel), 물질의 배치(batch of material), 그것을 만드는 공정(process) — 을 하나의 흐릿한 노드로 융합해 버리기 때문입니다. 셋을 떼어 두면 그래프는 무엇이든 말할 수 있고, 셋을 무너뜨려 합치면 무엇이 어디서 돌아갔는지조차 거의 말하지 못합니다.

쉽게 말하면

콘서트를 떠올려 보세요. 홀(hall)(여러 콘서트에 쓰임)이 있고, 공연(performance)(시작과 중간과 끝이 있는 하룻저녁)이 있으며, 그 녹음(recording)이 있습니다. 홀과 공연을 혼동하면 같은 홀에서 두 번의 콘서트가 열렸다고 말할 수 없습니다. 생산 바이오리액터도 똑같습니다. 용기(여러 배치에 쓰임)가 있고, 세포 배양 운전(성장과 생산이라는 악장을 가진 하나의 공연)이 있으며, 그것이 산출하는 제품의 배치가 있습니다. 이 장은 셋을 구별해서 유지합니다 — 바로 그것이 그래프로 하여금 이 용기가 저 운전을 호스팅했고 그 운전이 이 배치를 만들었다고 말하게 해 주는 것입니다.

이 장에서 다루는 내용

우리는 용기를 역할을 수행하는 장비로, 배치를 그것이 생산하는 물질로, 세포 배양 공정을 둘을 잇는 발생체(occurrent)로 모델링합니다 — 운전이 용기에 occursIn하고 배치를 hasOutput합니다 — 그런 다음 운전의 단계들(성장, 그다음 생산)을 하위 공정으로 모델링하고 설계 공간의 매개변수를 이 실제 운전에 붙입니다. 우리는 BATCH-2026-001 노드를 해부하는데, 그것은 Batch로만 타입이 매겨지고 그 밖에는 아니며, 용기는 별개의 개체로 따로 유지됩니다. 그리고 이제는 익숙해진 선 — 빽빽한 PAT 센서 스트림을 그래프 안에서는 색인하되 저장은 히스토리안에 맡기는 선 — 을 다시 긋습니다.

하나로 모델링하고 싶어지는 세 개의 엔티티

용기, 배치, 운전은 세 개의 BFO 범주이며, 척추 장(spine chapter)이 이미 이들을 분류해 두었습니다. 바이오리액터는 물질 엔티티(material entity) — 캠페인을 거쳐 지속되는 장비 — 로서 "이번 캠페인의 생산 리액터"라는 역할을 수행하며(bears the role), 그 역할은 배치가 끝나면 벗어 버립니다. 배치(BATCH-2026-001)는 다른 물질 엔티티입니다. 처음에는 배양액(broth), 그다음에는 항체를 담은 배양물로, 오직 이 운전 동안에만 존재합니다. 그리고 세포 배양 공정은 세포가 participate하는 발생체로서, 용기에 occursIn하고 배치 물질을 hasOutput하며 레시피를 realizes합니다. 이 셋을 모두 모델링한다는 것은, 같은 BR-101 용기가 지난달에 다른 배치를 돌렸다(새로운 물질, 새로운 공정, 같은 장비)고 그래프가 아무런 모순 없이 진술할 수 있다는 뜻입니다 — 바로 공리 장(axioms chapter)의 서로소(disjointness) 공리가 보호하는 능력입니다. Batch owl:disjointWith CellCultureProcess가 "배치가 곧 운전이다"라는 융합을 플래그가 달린 오류로 만들어 주고, Material owl:disjointWith Equipment가 더 미묘한 "배치가 곧 용기다"라는 융합에 대해 똑같이 해 줍니다 — 그래서 운전-대-용기 연결은 배치에 몰래 끼워 넣은 두 번째 rdf:type이 아니라 명시적인 occursIn 에지에 실립니다.

계보(genealogy) 에지도 여기서 놓입니다. BATCH-2026-001 derivedFrom SEED-001은 종균 배양의 세포를 생산 용기로 넘겨준 접종(inoculation)의 흔적입니다. 이 노드에서 사슬은 하류로 이어집니다 — 수확(harvest)이 이 배치를 derivedFrom하게 됩니다 — 그래서 생산 바이오리액터는 종균 배양으로부터 받아서 하류로 넘기는, 전체 계보의 경첩에 자리합니다.

단계는 라벨이 아니라 하위 공정이다

세포 배양 운전은 균일하지 않습니다. 서로 다른 규칙을 따르는 뚜렷한 단계들(phases)을 거칩니다 — 세포가 증식하는 성장 단계, 그다음 항체를 만드는 생산 단계 — 그리고 설계 공간은 각 단계마다 서로 다른 매개변수 범위를 지정하는 경우가 많습니다 [1]. 이 모델은 각 단계를 하위 공정(sub-process), 즉 전체 세포 배양 발생체의 시간적 부분(temporal part)으로 다루며, 각자 고유한 시작과 끝의 공정 경계(process boundaries)를 가집니다. 바로 이것이 그래프로 하여금 매개변수 설정값을 그것이 적용되는 단계에 붙이게 해 줍니다 — 생산 중에는 중요하지만 성장 중에는 그렇지 않은 공급 속도(feed rate)를, 분화되지 않은 통째의 운전이 아니라 해당 단계에 붙이는 것입니다. 단계는 레시피의 ISA-88 운영(operation)에 대응하는 발생체 쪽 짝입니다. 레시피는 단계를 정보로서 처방하고(prescribes), 운전은 그것을 사건으로서 실현하며(realizes), 둘은 한 단계씩 줄을 맞춰 대응합니다. 적재 가능한 데이터셋에서 운전은 성장/생산이라는 두 하위 단계를 가진 하나의 발생체이고, 배치는 그 출력이며, 단계별 매개변수 범위는 그것이 다스리는 단계에 매달립니다:

# instances.ttl — the run as an occurrent with growth/production sub-phases.
bp:CCP-001 a bp:CellCultureProcess ;
    bp:occursIn  bp:BR-101 ;                    # the run occurs IN the vessel...
    bp:hasInput  bp:SEED-001 ;
    bp:hasOutput bp:BATCH-2026-001 ;            # ...and the batch is its OUTPUT, not the run
    bp:hasPhase  bp:CCP-001-growth , bp:CCP-001-production ;
    bp:realizes  bp:Recipe-mAb-A ;
    bp:hasTrace  bp:Trace-BR101-Temp .
bp:CCP-001-production a bp:Phase ;              # a temporal sub-process...
    bp:setpoint 36.5 ; bp:norLow 36.0 ; bp:norHigh 37.0 ;   # ...with its own parameter range
    bp:realizesParameter bp:RPS-temp-CCP001 , bp:RPS-feedrate-CCP001 .   # the run's actual settings
bp:BATCH-2026-001 a bp:Batch ;                  # the material, typed ONCE — not also a Bioreactor
    bp:participatesIn bp:CCP-001 .
bp:BR-101 a bp:ProductionBioreactor .           # the vessel — a separate Equipment individual

개발에서 나온 매개변수가 마침내 붙을 운전을 갖다

공정 개발에서 우리는 bp:FeedRate bp:affectsQuality bp:MonomerPct-CQA를 증거와 범위를 갖춘 관계로 모델링했습니다 — 그러나 그것은 공정 일반에 관한 타입 수준(type-level) 사실이었습니다. 여기, 특정한 운전에서는, 그 매개변수가 인스턴스(instance)가 됩니다. 이 운전의 공급 속도가 이 설정값을 가졌고, 이 NOR 안에서 유지되었으며, 이 단계 동안 그러했고, 이 단량체(monomer) 결과를 냈다는 것입니다. 설계 공간은 무엇이 참이어야 하는지를 말했고, 운전은 무엇이 참이었는지를 기록합니다. 이 연결을 명시적으로 모델링하는 일 — 운전의 실제 매개변수 값이 레시피가 처방한 범위를 실현하는 것 — 이 바로 출하 게이트(release gate)와 모든 조사(investigation)로 하여금 실제 배치를 그것을 다스리는 지식에 비추어 점검하게 해 줍니다. 개발에서 나온 추상적인 affectsQuality 그래프와 공장에서 나온 구체적인 센서 기록이 이 노드에서 만납니다.

모델링된 상류의 경첩: 지속되는 용기가 역할을 수행하고, 성장 단계와 생산 단계를 가진 2주짜리 세포 배양 공정이 배치 물질을 산출하며, 설계 공간의 매개변수가 그것이 다스리는 단계에 붙고, 초 단위 센서 스트림은 트리플로 납작하게 펴지는 대신 히스토리안에서 참조됩니다. 저자가 AI의 도움을 받아 직접 제작한 그림입니다.

배치 노드의 해부, 그리고 깔끔하게 해소된 다중 소스 충돌

BATCH-2026-001을 풀어 보면 운전의 이야기 전체가 담겨 있습니다 — 그리고 그 이야기를 한 가지 종류의 사물, 즉 운전이 생산한 물질인 Batch로서 담고 있습니다. 그 단일 타입 매김은 오픈소스 지식 그래프 장이 드러내는 실제 통합 주름에 대한 의도된 수정입니다. 두 시스템이 이 물리적 운전을 기술했습니다. 배치 등록부(MES)는 그것을 배치라고 불렀고, 계보 로더(genealogy loader)는 포획 풀(capture pool)의 부모가 "바이오리액터에서 돌아갔다"고 기록했습니다. 그 소스들을 순진하게 합치면 하나의 노드를 Batch이면서 동시에 Bioreactor로 타입 매겨 버립니다 — 물질을 그것을 담은 용기와 융합하는, 바로 이 장이 경고하는 그 범주 오류입니다. 충실한 해소는 두 타입을 모두 유지하는 것이 아니라, 계보의 "바이오리액터"를 그것이 속한 자리로 보내는 것입니다. 즉 별개의 용기 BR-101로 보내고, 운전이 그것에 occursIn하게 하며, 각 rdf:type 주장이 서로 다른 소스에서 왔음을 기록하는 작은 PROV-O 흔적을 남기는 것입니다. 충돌은 해소되고, 출처는 보존되며, 어떤 노드도 양립 불가능한 두 BFO 범주를 걸치지 않습니다. 그러면 배치 노드는 SEED-001을 derivedFrom하고, 단계들을 가진 세포 배양 공정에 participates in하며, 운전의 실현된 매개변수 값을 지니고, SEC monomerPct 98.611을 담습니다 — 단량체는 사실 원액 단계(drug-substance-stage)의 출하 결과인데, 디지털 스레드(digital thread)가 그 발원 값을 읽을 수 있도록 여기 상류 배치에 붙여 둔 것이며, 완전히 충실한 출하 모델이라면 그것을 원액 로트(drug-substance lot)에 매달았을 것이라는 정직한 단서와 함께.

완전히 풀어낸 배치 노드: Batch로 한 번만 타입이 매겨지고, 용기는 별개로 유지되며(운전이 BR-101에 occursIn함), 종균 배양에서 파생되고, 단계로 나뉜 공정에 참여하며, 실현된 매개변수와 CQA를 지니고, 원시 스트림을 위해 히스토리안을 가리킨다 — 상류 계보와 품질이 하나의 주소에, 다중 소스의 용기/물질 충돌은 두 번째 타입이 아니라 출처로 화해되어. 저자가 AI의 도움을 받아 직접 제작한 그림입니다.

그래프는 센서 스트림을 색인하고, 히스토리안은 그것을 담는다

생산 운전은 PAT 데이터의 급류를 쏟아냅니다 — 온도, pH, 용존 산소, 그리고 그 밖의 것들이 몇 초마다 표집됩니다 [1][3]. 이것은 크로마토그램(chromatogram)과 똑같은 모양입니다. 트리플로 납작하게 펴서는 안 되는 빽빽한 시계열입니다. 그래서 그래프는 똑같은 색인-대-페이로드(index-versus-payload) 경계를 적용합니다 — 이 배치가 온도 신호를 hasTrace한다는 사실을 담고, 태그(BR101.Temp.PV)에 이름을 붙이며, 수백만 개의 점이 사는 히스토리안이나 데이터 그림자(data shadow)를 IRI로 가리키는 한편, 단일 설정값, 일탈 사건, 또는 단계 평균 결과는 타입이 매겨진 값으로서 그래프 안에 자리할 수 있습니다. 이것이 3부작이 거듭 수렴하는 정확한 아키텍처입니다. 서문의 태그와 데이터 책의 히스토리안 행은 페이로드이고, 그래프는 그것들을 찾을 수 있게 만들고 배치에 묶어 주는 색인입니다.

그렇다면 PI 태그는 어떻게 실제로 그래프 노드가 될까요? 점들을 복사해서가 아니라, 가상 그래프(virtual-graph) 엔진이나 R2RML/RML 처리기가 히스토리안 자체의 행 위에서 돌리는 매핑(mapping)을 통해서입니다. 동반 파일 historian-map.rml.ttl은 히스토리안의 한 행 — PI Web API 브리지가 생산하는 모양인 (ts, tag, value, unit, quality, batch_id) — 을 정확히 이를 위해 만들어진 W3C 어휘인 SOSA 관측(observation)으로 매핑합니다 [4][5]:

# historian-map.rml.ttl — one PI/historian row (tag BR101.Temp.PV) -> one sosa:Observation.
ex:ObservationMap a rr:TriplesMap ;
    rml:logicalSource [ rml:source "sensor_reading.csv" ; rml:referenceFormulation ql:CSV ] ;
    rr:subjectMap   [ rr:template "https://example.org/historian/obs/{tag}/{ts}" ;
                      rr:class sosa:Observation ] ;
    rr:predicateObjectMap [ rr:predicate sosa:observedProperty ;
                            rr:objectMap [ rr:template "https://example.org/historian/tag/{tag}" ] ] ;
    rr:predicateObjectMap [ rr:predicate sosa:hasSimpleResult ;
                            rr:objectMap [ rml:reference "value" ; rr:datatype xsd:float ] ] ;
    rr:predicateObjectMap [ rr:predicate bp:fromBatch ;
                            rr:objectMap [ rr:template "https://example.org/bioproc#{batch_id}" ] ] .

동반 매핑은 배치-와-태그마다 하나의 bp:hasTrace 에지 — 색인 — 를 내보내는 한편, 점들은 PI에 남습니다. PI Web API 스텁에서 기록된 몇 개의 값에 대해 historian_to_rdf.py를 돌려 보면 이 규율이 유지됨을 알 수 있습니다. 한정된 트리플 집합, 신호마다 하나의 트레이스 에지, 납작하게 펴진 스트림은 없습니다 [6]:

historian -> RDF: 23 triples from 3 rows
bp:hasTrace index edges (one per batch/tag — the stream stays in PI):
  BATCH-2026-001   hasTrace  https://example.org/historian/tag/BR101.Temp.PV
  BATCH-2026-001   hasTrace  https://example.org/historian/tag/BR101.pH.PV

미해결 과제: 시간, 연속성, 그리고 운전을 얼마나 모델링할 것인가

정직한 어려움들은 시간 주위에 몰려 있습니다. 트리플의 그래프는 근본적으로 무시간적입니다 — BATCH-2026-001 derivedFrom SEED-001에는 시계가 없습니다 — 그러나 바이오리액터 운전은 그 자체로 시간입니다. 단계, 램프, 일탈, 설정값 변경. RDF에서 시간적 범위를 표현하는 것은 가능하지만(공정 경계, 시간 구간, 타임스탬프가 찍힌 상태의 사물화) 장황하고 논쟁적이며 단일하게 지배적인 패턴이 없습니다. 그래서 대부분의 그래프는 시간을 거칠게 모델링합니다 — 한 단계에 시작과 끝이 있다 — 그리고 세밀한 시간적 거동은 히스토리안에 남겨 둡니다. 이는 합리적인 분할이지만, 그래프가 "pH 궤적의 모양은 어땠는가?"에 그래프를 떠나지 않고는 답할 수 없다는 뜻이기도 합니다. 그래프는 답이 어디에 사는지만 가리킬 수 있을 뿐입니다. 그래프가 시간적으로 무엇을 모델링하고 무엇을 유예할지 사이의 경계는 판단의 문제이며, 너무 많은 시간을 트리플에 모델링하는 것은 너무 적게 모델링하는 것만큼이나 실패입니다.

두 번째 어려움은 운전 자체의 입도(granularity)인데, 종균 배양이 제기했던 바로 그 개별화(individuation) 질문입니다. 단계는 몇 개인가? 공급 추가는 사건 노드인가, 아니면 그저 히스토리안의 한 점인가? 관류(perfusion) 운전은 하나의 연속 공정인가, 아니면 매일의 주기들의 연속인가? 정전적(canonical) 답은 없으며, 올바른 답은 그래프가 응대해야 할 질문에 달려 있습니다. 이 모델은 진정으로 강력합니다 — 실제 운전을 그것을 다스리는 지식 및 그 주변 계보에 묶어 줍니다 — 그러나 그것은 해상도가 주어진 것이 아니라 선택된 추상화이며, 권위 있어 보이는 그래프도 그것이 기술한다고 주장하는 공정보다 조용히 더 거칠 수 있습니다.

왜 중요한가

생산 바이오리액터는 전체 계보의 경첩이자, 개발 지식이 제조 증거와 만나는 곳입니다. 용기, 배치, 공정을 구별되는 엔티티로 모델링하면 그래프는 장비 재사용, 운전 계보, 단계별 통제를 한꺼번에 추론할 수 있습니다. 실현된 매개변수를 설계 공간에 붙이면 출하 결정을 그것을 정당화하는 지식에 비추어 점검할 수 있습니다. 센서 스트림을 통째로 삼키는 대신 색인하면 원시 데이터는 제자리에 머무는 동안 그래프는 질의 가능한 상태로 남습니다. 이 노드를 제대로 잡으면 디지털 스레드(digital thread)의 상류 절반이 견고해지고, 그 엔티티들을 융합하거나 시계열 트리플에 빠뜨리면 제조에서 가장 데이터가 풍부한 단계가 그래프에서 가장 신뢰할 수 없는 노드가 됩니다.

통신선에서 그래프까지

위의 historian-map.rml.ttl 브리지는 PI 행 — (ts, tag, value, unit, quality, batch_id) — 에서 출발합니다. 그러나 그 행은 신호가 시작되는 곳이 아닙니다. 한 홉 아래, 실제 바이오리액터에서 프로브는 DCS/PLC 위의 OPC UA 변수 노드이고, 한 번의 읽기는 DataValue — NodeId, Value, SourceTimestamp, StatusCode, 그리고 노드의 EUInformation 공학 단위 — 입니다. 동반 파일 examples/platform/ontology/opcua_to_rdf.py는 그 읽기들을 historian 맵이 주조하는 것과 동일한 sosa:Observation으로 매핑합니다 — NodeId의 문자열 식별자가 곧 historian 태그이기 때문입니다. 그래서 ns=2;s=BR101.Temp.PV와 태그 BR101.Temp.PV는 같은 관측 IRI로 떨어지고, EUInformation "Cel"은 qudt:hasUnit unit:DEG_C와 qudt:ucumCode "Cel"로 해석됩니다. 이제 전체 경로가 연속적입니다. 프로브 → OPC UA 노드 → historian 행 → sosa:Observation → bp:hasTrace 인덱스. (OPC UA는 통신선 단의 상용 단계입니다. 실험실 장비를 위한 OPC UA LADS는 아직 파일럿 단계입니다.)

# opcua_to_rdf.py — a read maps into the SAME sosa:Observation the historian map mints.
OPCUA_READS = [
    {"node_id": "ns=2;s=BR101.Temp.PV", "value": 36.51, "source_timestamp": "2026-03-02T08:00:10Z",
     "status_code": "Good", "eu_ucum": "Cel", "batch_id": "BATCH-2026-001"},
]
STATUS_TO_QUALITY = {"Good": 192}          # OPC UA StatusCode -> PI quality
UCUM_TO_QUDT      = {"Cel": UNIT["DEG_C"]} # EUInformation UCUM -> QUDT unit

# obs/{tag}/{ts} -> same IRI as the historian; the NodeId identifier IS the tag.
# OPC UA -> RDF: 16 triples from 2 variable reads

이제 단위는 더 이상 헐벗은 채로 다니지 않습니다. 실현된 설정값 bp:RPS-temp-CCP001은 이제 bp:setpointValue bp:RPS-temp-CCP001-qv를 지니는데, 이는 qudt:numericValue 36.5, qudt:hasUnit unit:DEG_C, qudt:hasQuantityKind qkind:Temperature, 그리고 qudt:ucumCode "Cel"을 가진 qudt:QuantityValue입니다 — 그리고 historian_to_rdf.py도 단위를 함께 방출합니다("historian -> RDF: 23 triples from 3 rows"). 같은 규율이 실제-실행(as-run) 기록에까지 미칩니다. b2mml_to_rdf.py는 examples/platform/ontology/b2mml/batch-production-record.xml을 읽어 그 배치 ID BATCH-2026-001을 bp:BATCH-2026-001로 바꾸고, 이를 bp:Batch로 한 번만 타입 지정합니다. 한편 기록의 장비 참조 BR-101은 실행 위의 bp:CCP-001 bp:occursIn bp:BR-101이 됩니다 — 엣지이지, 배치 위에 슬쩍 끼워 넣은 두 번째 rdf:type이 결코 아닙니다 — 그리고 페이즈별 실측치는 QUDT 수량값으로 실립니다("B2MML -> RDF: 8 triples from the master recipe, 25 more from the as-run batch record, 33 total"). Körber PAS-X와 Siemens Opcenter(상용 단계) 같은 실제 MES 플랫폼이 교환하는 것이 바로 이 B2MML입니다.

용기 자체도 여기서 그 맥락을 얻습니다. ISA-95는 이를 위계 안에 배치하고 — bp:BR-101 bp:isEquipmentPartOf bp:CELL-BR101 → bp:AREA-USP → bp:SITE-A → bp:ENT-Acme(유닛 → 프로세스 셀 → 영역 → 사이트 → 엔터프라이즈, 상용 단계) — 자산 관리 셸(Asset Administration Shell, IEC 63278, 제약 분야에서는 파일럿 단계)은 같은 물리적 사물을 명명합니다. bp:AAS-BR-101 a bp:AssetAdministrationShell ; bp:describesAsset bp:BR-101 ; bp:assetSerialNumber "BR101-SN-0001" ; bp:maxWorkingVolumeL 2000.0. 트윈의 자산 노드가 곧 온톨로지의 장비 노드이며, 이것이 현장과 디지털 트윈으로 하여금 하나의 바이오리액터를 하나의 정체성으로 말하게 해 주는 바로 그것입니다.

실제 현장에서는

단계로 나뉜 세포 배양 운전, 그 핵심 매개변수, 그리고 빽빽한 PAT 감시는 상업적 항체 생산이 작동하는 바로 그 방식이며, 포유류 세포 바이오리액터에서 여러 매개변수를 실시간으로 분광 감시하는 것은 확립된 관행입니다 [1][3]. 용기-배치-공정 구분은 모든 제어 시스템이 이미 따르는 ISA-88 배치 모델에 암묵적으로 들어 있습니다 [2]. 오픈소스 상류 장은 이 신호들의 실시간 포착을 보여 주며, 그것의 히스토리안은 이 장의 그래프가 hasTrace IRI로 가리키는 바로 그 저장소입니다. 온톨로지가 그 위에 더하는 것은 횡단적(cross-cutting) 질문을 던질 수 있는 능력입니다 — 어떤 배치들이 이 용기에서, 계대(passage) 한도 안에서, 어떤 매개변수를 유지하며 돌아갔고, 어떤 CQA를 냈는가 — 단일 제어 시스템이나 히스토리안 어느 하나로는 답할 수 없는 질문들입니다.

핵심 용어

• 바이오리액터(용기) — 장비, 즉 한 캠페인 동안 생산 리액터라는 역할을 수행하는 지속되는 물질 엔티티. 배치 및 운전과 구별됨.
• 배치(Batch) — 운전이 생산하는 물질(BATCH-2026-001). 오직 이 운전 동안에만 존재하며 종균 배양을 derivedFrom하는 물질 엔티티.
• 세포 배양 공정 — 용기에 occursIn하고, 세포가 참여하며, 배치를 출력하는 발생체. 배치와 서로소이므로 둘은 융합될 수 없음.
• occursIn — 운전을, 그것이 돌아간 지속되는 용기에 잇는 명시적 에지(BFO의 'occurs in'에 정렬됨). 배치를 장비로 타입 매기는 대신, 운전-대-용기 사실이 자리할 올바른 집.
• 단계(성장 / 생산) — 운전의 시간적 하위 공정으로, 고유한 경계를 가지며 단계별 매개변수 범위가 붙음.
• 실현된 매개변수(realized parameter) — 운전의 실제 설정값, 즉 설계 공간의 타입 수준 affectsQuality 범위에 대응하는 인스턴스 수준의 짝.
• 다중 소스 화해(multi-source reconciliation) — 두 시스템이 하나의 물리적 사물을 서로 충돌하는 타입으로 기술할 때, 그 수정은 각 주장을 올바른 엔티티에 매핑하고(여기서는 용기를 BR-101로) 출처를 기록하는 것이지, 하나의 IRI에 두 rdf:type을 모두 유지하는 것이 아님 — 후자는 Material owl:disjointWith Equipment가 오류로 플래그함.
• hasTrace(색인 대 페이로드) — 빽빽한 PAT 신호에 이름을 붙이고 IRI로 히스토리안을 가리키는 에지로, 초 단위 스트림을 트리플로 납작하게 펴지 않고 참조함.

다음 이야기

제품이 만들어졌고, 그것은 세포로 가득 찬 탱크 속에 떠 있습니다. 다음 장 수확과 청징 모델링: 하나의 물질 변환은 첫 하류 단계 — 항체를 담은 액체를 세포로부터 분리하는 일 — 을 하나의 물질을 소비해 둘을 생산하는 단위 공정(unit operation)으로 모델링하고, 이를 통해 모든 derivedFrom 에지 아래 도사린 질문에 맞섭니다. 정확히 어디서 하나의 물질이 끝나고 다음 물질이 시작되는가 하는 질문입니다.