Основни изводи
Кратък отговор: Историк на данни и релационна база данни са два начина за съхранение на данни, оптимизирани за различни видове данни.
Историк на данни (или процесен историк) е софтуер, специално създаден да улавя, компресира и съхранява високочестотни времеви серии от индустриални процеси, хиляди четения на тагове в секунда от сензори и системи за управление, с възможност за бързо извличане по времеви диапазон.
Релационната база данни е универсален софтуер, оптимизиран за структурирани транзакционни данни, организирани в таблици, с SQL заявки, връзки между записи и ACID транзакции. Историците са подходящи за времево маркирани потоци от сензори; релационните бази данни, за структурирани записи като поръчки, работни наряди и инвентар.
Те са допълващи се и повечето заводи използват и двете.
Историк на данни, наричан още процесен или оперативен историк, е софтуер, специално създаден да улавя, съхранява и извлича високочестотни времеви серии от индустриални процеси.
Неговата задача е да регистрира непрекъснатия поток от времево маркирани стойности, идващи от сензори, инструменти и системи за управление (PLC, SCADA, DCS): температури, налягания, дебити, обороти, статуси, често хиляди т.нар. тагове, вземани много пъти в секунда, денонощно, с години задържане.
За да се справи с този обем, историците използват специализирано хранилище за времеви серии с агресивна компресия (например алгоритми като deadband и swinging-door, които съхраняват само значими промени) и са оптимизирани за бързо извличане по времеви диапазон, „покажи стойностите на този таг през последната смяна“ се връща мигновено.
Историците са проектирани за реалностите на заводските данни: огромен входящ поток на записи, дълго задържане, заявки базирани на време и устойчивост. Те обикновено се интегрират директно с контролните слоеве и предоставят трендиране, агрегиране и достъп за анализ.
Определящата сила на историка е ефективното обработване на масивни, непрекъснати, времево маркирани данни от сензори, улавяйки пълната вярност на поведението на процеса във времето, компактно и възстановимо.
Той не е предназначен за сложни релационни заявки или транзакционно водене на записи; проектиран е да бъде високоскоростната временна памет на производствената площадка.
Релационна база данни (RDBMS) е универсален софтуер за съхранение на структурирани данни в таблици, оптимизиран за транзакции, връзки и сложни заявки.
Данните са организирани в таблици от редове и колони с дефинирани схеми, свързани помежду си чрез ключове и запитвани със SQL, което позволява мощно филтриране, обединяване и агрегиране през структурирани записи.
Релационните бази данни предоставят ACID транзакции (атомарност, консистентност, изолация, издръжливост), които гарантират целостта на данните при операции, които не бива да се изпълняват частично, жизнено важни за поръчки, плащания и движения на инвентара.
Те са отлични за структурирани, транзакционни и релационни данни: клиентски записи, работни наряди, инвентар, производствени записи, списъци с материали, всичко, което се вписва добре в свързани таблици и се нуждае от надеждни, последователни ъпдейти и богати заявки.
Определящата сила на релационната база данни е управлението на структурирани данни с целостта и гъвкавото запитване: тя налага последователност, моделира връзки и отговаря на сложни въпроси през данните.
Не е оптимизирана за екстремен входящ поток и извличане по време на високочестотни сензорни потоци, съхраняването на милиони бързи измервания във всяка обща релационна таблица е неефективно в сравнение с целеви историк.
Релационната база данни е работният кон за структурирани, транзакционни записи на завода, а не за суровия сензорен поток.
Ключовото различие е видът данни, за който всяка система е изградена: историкът е оптимизиран за високочестотни времеви серии от сензори, релационната база данни, за структурирани транзакционни данни. Тази разлика в предназначението определя всичко останало.
Историците използват хранилище за времеви серии със силна компресия и времево индексирано извличане, настроено за огромни скорости на запис и заявки „стойност във времето“; релационните бази данни използват таблици, схеми, ключове, SQL и ACID транзакции, настроени за структурирани записи, връзки и последователни ъпдейти.
Те отговарят на различни въпроси: историкът отговаря ефективно на „какво четеше този сензор на всеки секунда през миналата седмица?“; релационната база данни отговаря ефективно на „кои работни наряди за този актив са просрочени и какви части им трябват?“
Всеки е слаб в работата на другия: релационна база данни се затормозява при съхранение и заявки над милиони бързи сензорни измервания, а историкът не е създаден да моделира и транзактва структурирани релационни записи с гарантирана целост.
Затова те са допълващи се, а не взаимно изключващи: заводът генерира и двата вида данни, непрекъснат поток от процесни измервания (historian) и структурирани оперативни записи като поръчки и инвентар (релационна база данни), и всеки тип трябва да бъде в хранилището, създадено за него.
Изборът между тях е въпрос на съвпадение между данните и подходящия инструмент. (Модерните времеви бази данни размекват границата, предлагайки историк-подобна производителност за времеви серии с по-общи възможности за заявяване.)
Помислете за данните, които генерира една производствена линия. Машините ѝ стриймват високочестотни процесни данни: вибрации, температури, ток на мотора, брой цикли, статуси стартирай/спри, стотици тагове, измервани много пъти в секунда, непрекъснато.
Този поток принадлежи в историк на данни: той компресира и съхранява пълните времеви серии евтино и инженер може мигновено да изтегли тренд на всеки таг за произволен времеви прозорец, за да изследва проблем или да захрани анализ.
В същото време, същата операция произвежда структурирани, транзакционни записи: производствени поръчки, работни наряди за поддръжка, части изтеглени от инвентара, произведени партиди и техните решения за качество.
Тези принадлежат в релационна база данни: вписват се в свързани таблици, нуждаят се от консистентни транзакционни ъпдейти (издаването на част от инвентара трябва да завърши изцяло или да не се случи) и се заявяват релационно („покажи отворени работни наряди за този актив и частите, които изразходват“).
Опитът да се съхранява сензорният поток в релационната база данни ще я претовари; опитът да се управляват транзакционни работни наряди и инвентар в историка би бил непрактичен.
Линията се нуждае и от двете: историкът като високоскоростна памет за поведението на процеса; релационната база данни като система на записа за структурирани оперативни данни.
Често двете са свързани, като обобщени данни от историка се свързват със структурирани записи за отчети.
Избирайте според естеството на данните.
Използвайте историк на данни за високочестотни, времево маркирани процесни и сензорни данни, непрекъснатите измервания от машини и системи за управление, когато трябва да улавяте пълната вярност във времето, да компресирате масивни обеми и да извличате по времеви диапазон за трендове и анализи.
Използвайте релационна база данни за структурирани, транзакционни и релационни данни: поръчки, работни наряди, инвентар, производствени и качествени записи, всичко, което се вписва в свързани таблици и се нуждае от целост, последователни ъпдейти и сложни заявки.
В почти всеки завод отговорът е и двете, внедрени там, където всяка технология е най-силна: историкът като хранилище за времеви серии на процесния поток, релационната база данни като система на записа за структурирани оперативни данни, често интегрирани, за да могат данните да се анализират заедно.
Модерна подробност е времевата база данни (и облачните времеви услуги), която предлага историк-подобна производителност за времеви серии с по-широки възможности за заявяване и може да припокрива ролята на историка; при голям мащаб суровите данни от историка могат да захранват и езеро за данни за напреднал анализ.
Рамката за решение е проста: съпоставете хранилището с данните, времеви серии от сензори към историк (или времева база данни), структурирани транзакционни записи към релационна база данни, и ги интегрирайте, вместо да заставяте една система да върши работата на другата.
И двете хранилища захранват OEE по допълващ се начин.
Високочестотните машинни данни, които историкът улавя, състояния стартирай/спри, броячи цикли, обороти, сигнали за грешки, са суровото зърно, от което се изчисляват Availability и Performance на OEE; историкът често съдържа детайлните процесни данни зад загубите и е мястото, където се отива, за да се изследва защо е настъпила загуба.
Структурираните записи, които релационната база данни държи, работни наряди, производствени и качествени записи, причини за престой, доставят оперативния контекст и транзакционната страна на OEE, като данните за поддръжка и качеството, които обясняват и оценяват загубите.
Пълната картина на OEE обикновено свързва и двете: времевото доказателство за това, какво е правила машината (историк), със структурирани записи за поръчки, поддръжка и причини (релационна база данни).
Това се свързва и с разделянето между сурови и моделирани данни в разделението езеро за данни срещу хранилище за данни, и със системите за управление (SCADA и DCS), които генерират сигналите.
Но както при тях, съхранените сурови данни не са OEE сами по себе си, необходим е слой, който да превърне таговете в историка и записите в базата данни в модел за загуби Availability-Performance-Quality, който да движи подобрението.
Fabrico превръща машинните данни, било то стриймнати от контролния слой или съхранени в историк, в структурирана OEE картина на загубите, като ги свързва с оперативните записи (причини за престой, работни наряди, качество), които обясняват и оценяват загубите.
Вместо да оставя суровите времеви тагове в историка и транзакционните записи в отделна база данни, той предоставя разбивка по Availability, Performance и Quality върху и двете, така че данните да станат ясна представа за това къде се губи продуктивно време.
Запазете демонстрация, за да видите как вашите процесни и оперативни данни се превръщат в приложим OEE.
Историк на данни е софтуер, оптимизиран да улавя, компресира и съхранява високочестотни времеви серии от сензори в индустриални процеси, с бързо извличане по време. Релационната база данни е универсална, оптимизирана за структурирани транзакционни данни в таблици с SQL и ACID транзакции. Историците са подходящи за сензорни потоци; базите данни, за структурирани записи.
Защото високочестотните сензорни данни (хиляди измервания в секунда, в продължение на години) претоварват общите релационни таблици и бавят заявките по време. Историците използват специализирана компресия на времеви серии и времево индексирано извличане, създадени за този обем и модел на достъп, за които релационните бази данни не са оптимизирани.
За улавяне и съхранение на непрекъснатите, времево маркирани стойности от сензори и системи за управление (PLC, SCADA, DCS), температури, налягания, дебити, обороти, статуси, с висока честота, с компресия и бързо извличане на трендове. Той е високоскоростната временна памет на завода, използвана за трендиране, отстраняване на проблеми и анализ.
Да, обикновено. Историкът съхранява високочестотния процесен поток; релационната база данни е системата на записа за структурирани транзакционни данни като поръчки, работни наряди и инвентар. Всяка се използва там, където е най-силна, и често двете са интегрирани за общ анализ.
Високочестотните машинни данни на историка (състояния, броячи, обороти) са суровият материал за изчисляване на Availability и Performance на OEE, докато структурирани записи в базата данни (работни наряди, причини за престой, качество) доставят контекст и оценка на загубите. Пълната OEE картина свързва и двете, а слой ги превръща в модел на загубите, който стимулира подобрения.
Вход
Блог
