Stellix / NECI KYNOTA Open Bioprocess Data Integration and Controls Solution

Identyfikacja rekordu

KYNOTA jest platformą software, automatyki i integracji danych dla laboratoriów bioprocesowych. Łączy sterowanie oparte na DeltaV, webową wizualizację, urządzenia różnych producentów oraz kontekstualizację danych z bioreaktorów i analizatorów. Nie jest pojedynczym fermentorem, sterownikiem PLC ani serwerem o stałym BOM. Każde wdrożenie składa się z osobno dobranych bioreaktorów, peryferiów, kontrolerów, hostów, sieci i systemów danych.

Rekord opisuje linię KYNOTA jako rozwiązanie produktowo-usługowe. Sprzęt procesu zachowuje własne numery seryjne, firmware i podatności. Warstwa DeltaV zachowuje własny model kontrolerów, release i advisory. Bez takiego rozdziału ogólne hasło „KYNOTA” zasłania rzeczywistą powierzchnię ataku.

Oficjalny obraz ze strony KYNOTA przedstawia laboratorium i interfejs operatorski; metadane wskazują fotografię stockową.

Chronologia marki

NECI przejęło wcześniej aktywa Broadley-James BioNet i zapowiadało rozwijanie aplikacji opartej na DeltaV. Dnia 12 maja 2022 r. NECI ogłosiło KYNOTA jako subskrypcyjne, gotowe rozwiązanie integrujące sterowanie i dane bioprocesowe. Komunikat wymieniał laboratoria R&D i GMP, urządzenia różnych producentów oraz skalę od stanowisk stołowych do większych single-use bioreactors.

Dnia 17 sierpnia 2026 r. Stellix Group Inc. zunifikował Stellix Global Services, KYNOTA i Zaether pod marką Stellix; możliwości KYNOTA są obecnie linią produktową Stellix.

Relacja do BioNet

Historyczny Broadley-James BioNet Controller sterował Utility Towers przez DeltaV, a M3 rozdzielał funkcje na Pump Module, Gas MFC Module i Dual Vessel Utility Module. KYNOTA rozwija ten kierunek w warstwę vendor-agnostic: integruje urządzenia wielu OEM, dane, wizualizację i obsługę między laboratoriami.

Nie jest właściwe nazywanie KYNOTA „kolejnym modelem BioNet”. To platforma obejmująca software, usługi i projekty integracyjne. Starsze szczegóły BioNet — DeviceNet, FOUNDATION Fieldbus, konkretny kontroler MD czy układ pomp — nie przechodzą automatycznie na KYNOTA. Mogą występować w danej instalacji tylko wtedy, gdy są częścią zintegrowanego urządzenia lub projektu DeltaV.

Deklarowana architektura

Oficjalna infografika pokazuje kilka warstw: bioreaktor do zastosowań laboratoryjnych, skonfigurowany hardware process-control, subskrypcję z supportem i aktualizacjami, skonsolidowany data lake, zwirtualizowaną infrastrukturę serwerową oraz software do zbierania, integracji, interpretacji, warehousingu i wizualizacji danych.

Oficjalna infografika KYNOTA: process-control hardware/software, data lake, wirtualizacja i platforma danych. To model funkcjonalny, nie diagram sieci ani BOM.

Diagram KYNOTA potwierdza wirtualizowaną infrastrukturę serwerową i skonsolidowany data lake jako elementy oferty.

DeltaV jako warstwa automatyki

Karta NECI opisuje integrację automatyki DeltaV z vendor-agnostic connectivity, web-based visualization i information management.

Inwentaryzacja musi objąć kontrolery, carriers/I/O, ProfessionalPLUS, operator stations, Application Stations, historian, serwery batch, domenę i urządzenia sieciowe. Każdy komponent otrzymuje model, hardware revision, firmware/software, funkcję, właściciela i zależność. Numer wersji aplikacji KYNOTA nie zastępuje release'u DeltaV.

Warstwa Controls & Automation

KYNOTA deklaruje kontrolę i monitoring w czasie rzeczywistym, parameter management, ustawianie alarmów, zmiany sond oraz kalibrację sensorów i pomp. Obsługiwane modalności obejmują batch, fed-batch i perfusion. Platforma ma umożliwiać runtime configuration przez użytkownika końcowego oraz korzystanie z szablonów eksperymentalnych.

Oficjalna grafika sekcji Control, łącząca operatora, webowy ekran i sprzęt procesu. Nie ujawnia produktu HMI ani endpointu.

Zmiana konfiguracji podczas runtime ma duży promień rażenia. Trzeba rozróżnić edycję parametrów eksperymentu, zmianę strategii, zmianę połączenia urządzenia i modyfikację logiki sterowania. Wymagane są role, zatwierdzenie, wersjonowanie, audit trail i możliwość powrotu do zatwierdzonego stanu. Publiczne strony nie opisują tych mechanizmów.

Warstwa Hardware

Sekcja „Hardware” na stronie KYNOTA opisuje wyposażenie laboratoryjne — bioreaktory, fermentory i peryferia do regulacji parametrów. Nie przedstawia nazwanego appliance serwerowego. Sprzęt dobierany jest do procesu i lokalizacji, więc rekord KYNOTA nie ma jednej pojemności, mocy, wymiarów ani procesora.

Oficjalna grafika sekcji Hardware pokazuje dwunaczyniowe stanowisko jako przykład integrowanego sprzętu. Nie jest deklaracją jednego obowiązkowego modelu.

Web-based visualization

Webowa wizualizacja jest funkcją KYNOTA potwierdzoną wprost.

Fotografia ilustracyjna użyta przez oficjalną stronę Control; nie przedstawia identyfikowalnego modelu KYNOTA.

Dostęp mobilny, powiadomienia i remote access

KYNOTA wymienia mobile accessibility, powiadomienia push/text/email, zgodność z platformami zdalnego dostępu oraz multi-site information sharing.

Powiadomienie nie jest kanałem sterowania, dopóki nie ma funkcji odpowiedzi lub linku do sesji uprzywilejowanej. Mimo to może ujawniać nazwy procesów, alarmy i adresy. Należy sprawdzić treść wiadomości, listę odbiorców, retencję u operatora, mechanizm rezygnacji i zachowanie po zmianie roli pracownika.

Dostęp między lokalizacjami wymaga jawnej topologii: site-to-site VPN/SD-WAN, routing, DNS, identity federation, certyfikaty i reguły firewall. Hasło „multi-site” nie rozstrzyga, czy dane są kopiowane centralnie, federowane czy widoczne przez zdalny UI.

Konta, role i uwierzytelnianie

W badaniu zbiera się źródło tożsamości, grupy, role aplikacyjne, service accounts, tokeny/API keys, certyfikaty, konta awaryjne i historię logowania. Wspólne konto laboratoriów uniemożliwia atrybucję, nawet jeśli proces operacyjny działa poprawnie.

Parameter management i templates

Parameter management, eksperymentalne templates, run comparison i runtime configuration są funkcjami deklarowanymi. Parametr musi mieć nazwę, jednostkę, typ, zakres, domyślną wartość, źródło, wersję i zakres obowiązywania. Inaczej skopiowanie szablonu między skalami może przenieść poprawną liczbę o błędnym znaczeniu.

Szablon powinien być niemutowalnym release'em po zatwierdzeniu. Zmiana tworzy nową wersję, a run wskazuje dokładny identyfikator wersji. Ważne są diff, autor, zatwierdzający, czas, powód i lista stanowisk. Publiczny opis nie potwierdza sposobu implementacji, więc są to wymagania odbiorcze, nie przypisane funkcje.

Batch, fed-batch i perfusion

Batch wymaga kontroli etapów i warunków przejścia. Fed-batch dodaje profile dozowania, całkowitą dawkę, kalibrację pomp i warunki przerwania. Perfusion wymaga równowagi dopływu/odpływu, kontroli objętości, retencji komórek oraz reakcji na awarię pompy lub sensora.

Modalność platformy nie jest gotową recepturą GMP. Każdy proces ma własne nastawy, limity, interlocki, audit trail i walidację. Funkcja „borrow equipment from other stations” nie może pozwolić na użycie urządzenia z niezgodną kalibracją, zakresem lub jednostką.

Integracja Raman, PAT i nowych sensorów

Strona Control wskazuje możliwość integracji Raman, PAT i nowych sensorów.

Warstwa danych

KYNOTA Data deklaruje połączenie, gromadzenie i kontekstualizację danych eksperymentalnych w czasie rzeczywistym, przechowywanych w jednym miejscu. Wymienione dane bioreaktora to pH, temperatura i DO. Źródła offline/at-line obejmują viable cell density, blood gas analyzers, metabolite analyzers, cell counters i spectroscopy. Systemy docelowe lub sąsiadujące to historian, ELN i LIMS.

Fotografia ilustracyjna strony Data przedstawia ręczną dokumentację laboratoryjną; nie jest zrzutem aplikacji KYNOTA.

Kontekstualizacja danych

Wywiad branżowy z przedstawicielem KYNOTA wskazuje przykłady kontekstu: medium, objętość, pochodzenie komórek, naczynie i czas próbki. Kontekst musi wiązać dane czasu ciągłego z próbką, analizatorem i runem. Sama kolumna timestamp bez źródła czasu i strefy nie wystarcza.

Transfer między R&D i GMP

KYNOTA ma ułatwiać tech transfer oraz dzielenie danych, konfiguracji i templates między laboratoriami, budynkami i krajami. Transfer nie jest automatyczną kwalifikacją GMP. Wymaga zatwierdzonego mapowania skali, jednostek, tagów, sprzętu, alarmów i wymagań regulacyjnych.

Stellix w komunikacie z 2026 r. kładzie nacisk na prace w aktywnych regulowanych środowiskach i długoterminowe wsparcie po go-live. Jest to deklaracja modelu usługowego, nie dowód spełnienia konkretnego 21 CFR Part 11 lub Annex 11 przez każde wdrożenie. Zgodność ustala się z URS, risk assessment, testami i dokumentacją konkretnej konfiguracji.

SaaS i hosting

Producent określa KYNOTA jako SaaS subscription; infografika pokazuje zwirtualizowaną infrastrukturę serwerową, a opis wspomina konfiguracje site-based.

W umowie trzeba wskazać controller/processor, lokalizację i przepływ danych, subprocessorów, regiony, mechanizm wsparcia, telemetry, logi, patching, odpowiedzialność za tożsamość i procedurę wyjścia. Bez tego nie da się wiarygodnie narysować granicy zaufania.

Aktualizacje i evergreen design

Subskrypcja obejmuje support, major version upgrades, hot fixes i regular updates; producent deklaruje możliwość planowania go-live według harmonogramu laboratorium.

Proces zmiany powinien obejmować identyfikator wersji, SBOM, ocenę advisory, staging, test regresji integracji, backup, zatwierdzenie, okno, rollback i dowód powdrożeniowy. „Evergreen” nie może oznaczać niekontrolowanej aktualizacji w trakcie runu. Zespół musi znać elementy aktualizowane przez dostawcę i pozostające odpowiedzialnością klienta.

Źródła

• KYNOTA — oficjalna karta rozwiązania i status linii Stellix.
• KYNOTA Control — web, mobile, remote access, integracje i lifecycle.
• KYNOTA Data — dane bioreaktora, analizatory, historian, ELN i LIMS.
• KYNOTA Hardware — zakres integrowanego sprzętu.
• KYNOTA — About Us.
• KYNOTA — Request a Quote.
• NECI — KYNOTA Open Bioreactor Solution.
• NECI — uruchomienie KYNOTA 12 maja 2022 r..
• Stellix — unifikacja marek 17 sierpnia 2026 r..
• GEN — Adding Context to Bioprocessing Data.
• NVD — CVE-2022-29957 jako kandydat zależny od DeltaV.
• NVD — CVE-2018-19021 jako kandydat zależny od wersji DeltaV.
• Stellix — Terms and Conditions.