Przemysłowe systemy informatyczne oparte na bazach

V Konferencja PLOUG
Zakopane
Październik 1999
Przemysłowe systemy informatyczne oparte
na bazach danych Oracle
dr inż. Jan Baranowski
Thomson Polkolor
Autor
Dr inż. Szef Służby Informatyki w Thomson Polkolor. Od 12 lat odpowiedzialny za tworzenie systemów
informatycznych wcześniej w Polkolorze a obecnie w Thomson Polkolor.
Streszczenie
Przedstawione zostaną przemysłowe systemy informatyczne, wykonane i wdrożone w Thomson Polkolor,
oparte na bazach danych Oracle. Omówiony zostanie proces projektowania tych systemów (z wykorzystanie
narzędzi CASE), oraz przedstawione zostaną przykłady rozwiązań technicznych: od bezpośredniego
zbierania danych na linii produkcyjnej aż do organizacji systemy raportowania z wykorzystaniem hurtowni
danych.
1. Wstęp.
Zapewnienie rynków zbytu dla produkcji przemysłowej wymaga ciągłego udoskonalania
produktów, ciągłego podnoszenia ich jakości oraz zmniejszania kosztów jednostkowych
produkcji poprzez poprawianie uzysków. Do pewnego poziomu jest to możliwe poprzez
ręczną kontrolę i sterowanie procesem. Jednak przy zwiększającej się produkcji i coraz
wyższych wymaganiach jakościowych staje się to niemożliwe bez odpowiednich
systemów informatycznych, służących do zbierania i analizy danych ilościowych i
jakościowych.
Taką drogę przeszedł również THOMSON POLKOLOR. Od produkcji na poziomie
kilkuset tysięcy lamp rocznie za najlepszych czasów byłego Polkoloru i uzyskach daleko
odbiegających od poziomu światowego, doszliśmy do ponad 4 milionów kineskopów w
roku bieżącym i jakości na najwyższym poziomie światowym. Wymagania konkurencji
rynkowej stawiają wciąż nowe, wyższe wymagania, którym nie można by sprostać bez
odpowiednich systemów informatycznych obsługujących produkcję.
Gdy w roku 1993 dokonano wyboru zintegrowanego systemu zarządzania
przedsiębiorstwem, wydawało się, że zaspokoi on wszystkie potrzeby informatyczne,
również w zakresie rozliczania produkcji, analizy jakościowej i śledzenia wpływu partii
materiałów i parametrów procesowych na uzyski. Szybko okazało się to nierealne.
Różnorodność procesów produkcyjnych, od czysto mechanicznych do skomplikowanych
reakcji fizykochemicznych, związana z tym różnorodność parametrów oraz zakresów i
postaci analiz spowodowały, że żaden „gotowy” system nie mógł sprostać wymaganiom w
tym zakresie. Dlatego podjęto decyzję o realizacji przemysłowych systemów
produkcyjnych we własnym zakresie i „na własną miarę” w oparciu o standardy
obowiązujące w THOMSON’ie: bazy danych ORACLE i narzędzie programistyczne
SQLWindows firmy Centura.
2. Proces projektowania i wdrażania systemów informatycznych w THOMSON
POLKOLOR.
Aby projektowanie i wdrażanie systemów informatycznych odbywało się sprawnie i
przynosiło spodziewane efekty, konieczne jest oparcie się na sprawdzonej metodyce. Od
1993 roku THOMSON POLKOLOR wykorzystuje metodykę CASE firmy LBMS
wspomaganą produktem tej firmy (obecnie własność firmy SELECT) o nazwie Systems
Engineer.
Cykl wykonania projektu, zgodnie z metodyką LBMS, składa się z wielu etapów, których
omówienie przekracza ramy niniejszego referatu. Poprzestanę więc na wymienieniu
najważniejszych:
- inicjacja projektu,
- analiza wymagań krytycznych,
- przygotowanie modelu procesów,
- przygotowanie modelu danych,
- analiza zadań,
- przygotowanie modelu obiektów użytkownika,
- przygotowanie projektu aplikacji,
- definicje widoków, procedur i wyzwalaczy,
- wykonanie aplikacji zgodnie z przyjętymi standardami,
- wdrożenie systemu.
2
Końcowym efektem projektu (zapisanym w Systems Engineer’ze) jest:
- specyfikacja wymagań określająca cel projektu, definicje wymagań i uzgodnione rozwiązania,
- kontekstowy diagram przepływu danych (granice systemu, obiekty zewnętrzne, przepływy),
- fizyczny model danych opisujący bazę danych,
- skrypty generujące bazę danych łącznie z definicjami widoków, procedur i wyzwalaczy,
- definicje klas użytkowników, ich funkcje i zakres wykorzystywania systemu,
- scenariusze zadań wykonywanych przez użytkowników oraz skrypty do prototypowania,
- definicje obiektów użytkowników,
- projekty aplikacji definiujące okna aplikacji, zawartość okien, nawigację pomiędzy oknami i
akcje w oknach powiązane z akcjami na danych.
Jest to materiał zarówno dokumentujący projekt, jak i umożliwiający automatyczne
wygenerowanie bazy danych oraz szybkie napisanie kodu aplikacji. Oczywiście
ostatecznym efektem realizacji projektu jest działający system z dokumentacją systemową
i użytkową, procedurami standardowymi i awaryjnymi, przeszkolonymi użytkownikami i
zapewnioną codzienną obsługą. Przeprowadzana jest także analiza osiągnięcia
zakładanych celów projektu.
Należy podkreślić, że wszystkie etapy projektowania wykonywane są wspólnie z
przedstawicielami przeszłych użytkowników systemu, a często nawet bezpośrednio przez
nich.
W celu zapewnienia jednolitego i sprawnego przebiegu procesu wytwarzania
oprogramowania, przyjęto różnorodne standardy dotyczące m.in. wykorzystywanych
narzędzi, sposobu ich wykorzystywania, procedur awaryjnych, dokumentacji technicznej i
użytkowej, wyglądu okien i sposobu nawigacji itp. Standardy dotyczące sprzętu i
oprogramowania zatwierdzane są na poziomie całego THOMSONa. Oto niektóre z ich:
System operacyjny
Baza danych
Narzędzie do tworzenia aplikacji
Narzędzie do raportowania
Narzędzie do zasilania hurtowni danych
Windows NT 4.0(server lub workstation)
Oracle
SQLWindows/32 Centura
Business Objects
Powermart/Powercenter Informatica
3. Przykłady zastosowania przemysłowych systemów informatycznych.
Z pośród wielu systemów wykorzystywanych w produkcji przedstawię bliżej dwa
przykłady związane ze śledzeniem wyrobu oraz system raportowania.
3.1. System nalepkowania kineskopu.
Podstawowym zadaniem tego systemu jest oznakowanie kineskopu etykietą gwarancyjną,
zawierającą jego unikalny numer. Numer ten generowany jest na operacji zatapiania szyjki
kineskopu i nanoszony na kineskop w postaci nalepki z kodem kreskowym. Kod ten
zawiera m.in. informacje o typie kineskopu. Na poszczególnych operacja produkcyjnych
powstają kolejne zapisy w bazie danych dotyczące: czasu wykonania operacji, parametrów
technologicznych, zastosowanych partii materiałów, osób wykonujących operacje itp.
3
System nalepkowania składa się z czterech stanowisk:
a. Stanowisko mistrza służące do wykonania operacji administracyjnych
konfiguracyjnych systemu oraz wykonywania raportów i analiz.
i
b. Stanowisko nalepkowania. Na stanowisku tym czytnik kodów kreskowych odczytuje
identyfikator nadjeżdżającego kineskopu. System odczytuje typ kineskopu i na tej
podstawie podpowiada operatorowi możliwe dla danego typu wersje kineskopu.
Operator (na podstawie wizualnej oceny) dokonuje wyboru wersji kineskopu,
wciskając odpowiedni przycisk na ekranie dotykowym. Następuje wydrukowanie
etykiety gwarancyjnej, zawierającej m.in. numer kineskopu (przeniesiony z odczytanej
etykiety) w postaci jawnej i kodu kreskowego. Informacje zawierające: numer
kineskopu, jego typ i wersję, czas wykonania operacji oraz identyfikator operatora
zapisywane są do bazy danych. Operator nakleja etykietkę gwarancyjną we właściwe
miejsce na kineskopie. Częstotliwość wykonywania operacji: 6-7 sekund.
c. Stanowisko weryfikacji. Na stanowisku tym umieszczone są dwa czytniki kodu
kreskowego. Jeden z nich odczytuje identyfikator z nalepki naklejanej na operacji
zatapiania szyjki a drugi identyfikator z etykiety gwarancyjnej. Jeśli identyfikatory te
nie są identyczne lub nie można odczytać któregokolwiek z nich, generowany jest
sygnał dźwiękowy i kineskop trafia na stanowisko analityka. Jeśli identyfikatory są
zgodne, odpowiedni zapis trafia do bazy danych.
d. Stanowisko analityka. Na stanowisku tym analizowana i usuwana jest przyczyna
niezgodności identyfikatorów na obu etykietach. Może to być wynikiem nieczytelności
jednej z etykiet, braku jednej z etykiet lub błędu operatora na stanowisku
nalepkowania. Dokładna procedura postępowania zapisana jest w systemie, który
podpowiada analiście kolejne kroki jakie ma wykonać. Efektem działania analisty jest
zapewnienie czytelności identyfikatora na etykiecie gwarancyjnej. Może wiązać się to
z jej powtórnym wydrukowaniem lub, w krańcowym przypadku, z wygenerowaniem
numeru awaryjnego i wydrukowaniem go na nowej etykiecie gwarancyjnej.
Oczywiście to ostatnie traktowane jest jako ostateczność, gdyż powoduje utratę całej
informacji technologicznej o kineskopie.
4
Schemat funkcjonalny sytemu przedstawiony jest na rysunku 1.
b) Stanowisko nalepkowania
a)
Stanowisko
mistrza
c) Stanowisko
weryfikacji
d) Stanowisko
analityka
NET
(TCP/IP)
Rys 1.
3.2 System Pakownia.
Podstawowym zadaniem systemu Pakownia jest zidentyfikowanie kineskopów
pakowanych do kolejnych palet. Paleta zawiera zazwyczaj 24 kineskopy ułożone w trzy
warstwy po 8 kineskopów w każdej warstwie. Paleta posiada unikalny numer i przynależy
do konkretnej partii wysyłanej do konkretnego klienta. Posiadanie tej informacji
umożliwia identyfikację kineskopów wysłanych do danego klienta (wraz z całą wiedzą
technologiczną o nich) lub zidentyfikowanie klienta do którego dany kineskop został
wysłany (np. gdy na podstawie analizy parametrów technologicznych zachodzi
podejrzenie, że jest on wadliwy). Dodatkowym celem jest zapewnienie zgodności typu i
wersji kineskopów w palecie.
System składa się ze stanowiska mistrza oraz dziesięciu stanowisk pakowania.
a. Stanowisko mistrza służy do wykonania operacji administracyjnych i konfiguracyjnych
systemu, drukowania nalepek na palety oraz wykonywania raportów i analiz.
5
b. Stanowiska pakowania służą do identyfikacji kineskopów pakowanych do
poszczególnych palet. Na początku operator odczytuje skanerem ręcznym etykietę
palety. Na podstawie identyfikatora palety pobierana jest z bazy danych informacja o
typie, wersji i ilości kineskopów, które mają być do tej palety zapakowane. Po
zapakowaniu pierwszej warstwy, operator uruchamia specjalny czytnik kodów
kreskowych zawieszony nad stanowiskiem, który odczytuje identyfikatory kineskopów
zapakowanych do tej warstwy. Na podstawie informacji w bazie danych sprawdzana
jest zgodność typów i wersji kineskopów. Wszelkie niezgodności (lub brak odczytu
identyfikatorów) sygnalizowane są operatorowi, który podejmuje odpowiednie
działania. Podobnie pakowane są następne warstwy palety. Cała informacja o
zawartości palety zapisywana jest do bazy danych.
Schemat funkcjonalny systemu przestawia rysunek 2.
Stanowisko
pakowania nr. 1
Stanowisko mistrza
Stanowisko
pakowania nr.10
NET
(TCP/IP)
Rys.2
6
3.3 System raportowania.
System raportowania stanowi wypracowany standard obowiązujący w całym Zakładzie w
tym również w systemach produkcyjnych. Ogólną strukturę tego systemu przedstawiono
na rysunku 3.
Użytkownicy
Internet
Explorer
Internet
Explorer
Business
Objects
Aplikacje
raportujące
Raporty
sytemów
trasakcyjnych
Systemy
transakcyjne
Web
Intelligence
Repozytorium
Business Objects
Raporty osobiste
Raporty rozsyłane
Raporty globalne
Bazy danych
systemów
transakcyjnych
Powermart
Baza danych
hurtowni
Rys. 3
System raportowania składa się z następujących elementów:
-
Bezpośrednie raportowanie z systemów transakcyjnych.
Są to standardowe raporty systemów transakcyjnych oraz dodatkowe raporty, wykonane w
tym samym narzędziu w którym został napisany system transakcyjny i zintegrowane z tym
systemem. Są to zazwyczaj typowe wydruki systemu, potwierdzające wykonanie transakcji
lub raportujące aktualny stan systemu bez angażowania zbyt dużej ilości danych.
7
-
Raporty z systemów transakcyjnych udostępniane przez intranet.
Są to raporty przekrojowe o ustalonej formie i zawartości danych (np. raporty dzienne,
tygodniowe), generowane bezpośrednio z systemu transakcyjnego lub też z jego bazy
danych i umieszczane jako strony statyczne w internecie. Rozwiązanie to zastąpiło
rozsyłanie raportów drogą elektroniczną. Adresatami tego rozwiązania są osoby
korzystające z raportów w sposób bierny, tzn. bez potrzeby wykonywania dodatkowych
analiz.
-
Raportowanie przy pomocy Business Objects bezpośrednio z transakcyjnej bazy
danych.
Rozwiązanie to stosowane jest w mocno ograniczonym zakresie (ze względu na możliwość
znacznego obciążenia transakcyjnej bazy danych) tylko tam, gdzie niezbędna jest analiza
danych na bieżąco. Ma to szczególne zastosowanie przy bieżącej kontroli uzysków, widma
wad itp.
-
Raportowanie przy pomocy hurtowni danych.
Jest to preferowany sposób raportowania. Ma tę przewagę nad wcześniej przedstawionymi
rozwiązaniami, że nie zaburza funkcjonowania systemów transakcyjnych, nawet jeśli
wykonywane są bardzo złożone analizy. Umożliwia użytkownikom korzystanie z
wcześniej zdefiniowanych raportów z możliwością dowolnego ich zmieniania, albo
tworzenia własnych raportów lub analiz. Stosowane jest wszędzie tam, gdzie nie jest
wymagana natychmiastowa analiza nowych danych, lecz raczej analiza danych z
dłuższego okresu.
Proces ten zorganizowany jest w ten sposób, że okresowo, zazwyczaj raz dzienne, dane za
poprzedni okres pobierane są z baz transakcyjnych i przenoszone do bazy hurtowni
danych. Odbywa się to w nocy lub w innych momentach tak dobranych, aby nie zakłócać
działania systemu transakcyjnego. Przenoszone dane są przetwarzane i ewentualnie
agregowane w ten sposób, aby ułatwić wykonywanie typowych raportów. Oprócz zasilania
hurtowni danymi detalicznymi, zasilane są data marty tematyczne, zoptymalizowane pod
odpowiednie typy analiz. Użytkownik widzi dane poprzez tzw. światy obiektów,
zawierające intuicyjnie zrozumiałe cegiełki z których można, bez posiadania wiedzy
informatycznej, budować dość dowolne raporty i analizy. Oczywiście większość
użytkowników korzysta z wcześniej zdefiniowanych raportów, które mogą być
automatycznie odświeżane w momencie ich otwierania lub odświeżane przez użytkownika
z podaniem zakresów analizy. Użytkownicy mogą wykorzystywać system na dwa
sposoby: poprzez instalację klienta Business Objects na własnym komputerze lub przez
intranet. Pierwsze rozwiązanie przeznaczone jest dla użytkowników o większych
potrzebach w zakresie raportowania, zarówno co do ilości raportów jak też ich złożoności.
Wiąże się oczywiście z instalacją Business Objects na komputerze użytkownika. Drugie
rozwiązanie preferowane jest dla szerszej grupy użytkowników, którzy możliwość
raportowania wykorzystują sporadycznie i korzystają w głównej mierze z gotowych
szablonów raportów. Nie jest w tym przypadku potrzebna instalacja na komputerze
użytkownika, co ma niebagatelne znaczenie przy dużej liczbie instalacji, a możliwości
tworzenia raportów są tylko nieznacznie ograniczone. Business Objects i Web Inteligence
korzystają z tych samych repozytoriów i tych samych światów obiektów. Raporty,
utworzone przy pomocy Business Objects, mogą być oglądane i odświeżane (chociaż nie
8
modyfikowane) poprzez Web Inteligence. W sumie tworzy to dość elastyczny i wydajny
system raportowania dający się dobrze zaadoptować do większości potrzeb.
4. Podsumowanie.
Kilkuletnia eksploatacja przemysłowych systemów informatycznych opartych na bazach
danych ORACLE prowadzi do następujących wniosków:
a. Bazy danych ORACLE sprawdzają się w tych zastosowaniach.
W nieco wcześniejszych rozwiązaniach podejmowane były próby wykorzystywania
innych, tańszych baz danych. Ze względu na problemy techniczne (częste zawieszanie się
serwerów, uszkodzone indeksy itp.) zrezygnowano z tych rozwiązań. Od kiedy
zastosowano bazy danych ORACLE, problemy te praktycznie nie występują.
b. Konfiguracja: serwer oparty na procesorze Intel, Windows NT, Oracle jest
wystarczająca do tego typu zastosowań.
Praktyka pokazała, że (mimo wcześniejszych wątpliwości) taka konfiguracja jest
całkowicie wystarczająca dla systemów rejestrujących po kilkanaście tysięcy transakcji
dziennie z każdego stanowiska. Jest to istotne ze względu na koszty serwerów.
c. Wypracowane rozwiązania, w tym rozwiązania awaryjne, sprawdziły się w praktyce.
Kilkuletnia przemysłowa eksploatacja systemów wykazała, że są one wystarczająco
niezawodne, a procedury awaryjne (w tym buforowania danych w przypadku braku
łączności z serwerem) działają sprawnie. Oczywiście pewne elementy tych rozwiązań były
w tym czasie poprawiane i ulepszane, ale podstawowe rozwiązania przetrwały próbę
czasu.
d. Systemy przemysłowe będą dalej rozwijane w oparciu o wypracowane standardy.
Rosnące wymagania odnośnie zakresu informacji zawartych w systemach przemysłowych
powodują konieczność dalszej ich rozbudowy i dopisywania nowych modułów. Prace te są
i będą dalej prowadzone w oparciu o wypracowane rozwiązania.
W zakresie tworzenia spójnego systemu raportowania doświadczenia THOMSON
POLKOLOR są mniejsze i ograniczają się do kilkunastu miesięcy. System ten jest cały
czas w trakcie implementacji, a prace nad nim przewidywane są na minimum 15 miesięcy.
Jednak już teraz przedstawić można pierwsze wnioski wynikające z tych doświadczeń.
a. Konieczna jest jasna i spójna wizja systemu raportowania.
Tworzenie raportów w dowolny, wymyślony przez użytkownika (bądź programistę)
sposób jest zbyt kosztowne i niebezpieczne aby mogło być zaakceptowane. Rozwiązania
takie są zwykle nieudokumentowane i, po ewentualnym odejściu osoby która je wykonała,
niemożliwe do dalszego wykorzystywania. Jakość i użyteczność takich raportów jest
zazwyczaj wątpliwa, a lokalność stosowania powoduje, że podobne w treści raporty są
wykonywane w różny sposób, w różnej formie i często z różnymi wynikami przez różne
osoby.
9
b. Konieczne jest ustanowienie standardów w zakresie narzędzi i sposobu wykonywania i
dokumentowania raportów.
Wykorzystywanie standardowych narzędzi i rozwiązań zapewnia redukcję kosztów zakupu
licencji oraz umożliwia łatwą modyfikacje raportów przez osoby inne niż ich autorzy.
c. Efektywny i bezpieczny system raportowania powinien być oparty o hurtownię danych.
Zastosowanie hurtowni danych separuje system raportowania od systemu transakcyjnego.
Likwidowane jest niebezpieczeństwo zaburzenia pracy systemu transakcyjnego poprzez
nadmierne obciążenie serwera bazodanowego skomplikowanym zapytaniem. W hurtowni
danych struktura przechowywanych danych może być optymalizowana pod kątem
najczęściej wykonywanych analiz, co znacznie poprawia efektywność raportowania.
Spójność i bezpieczeństwo danych mogą być również w wydatny sposób poprawione.
d. Hurtownia danych może być realizowana przyrostowo, jednak od początku należy
zwracać uwagę na jej jednolitość.
Istnieje pokusa niezależnego realizowania poszczególnych data martów, celem szybkiego
uzyskania efektów. Jest to możliwe do realizacji, ale konieczne jest posiadanie
przynajmniej wizji docelowej hurtowni danych jako spójnej struktury. Przy dalszym
rozwoju data martów okazuje się bowiem, że ich część wspólna jest coraz większa a
problemy z ich połączeniem w jedną całość mogą być znaczne.
Zarówno w przypadku tworzenia systemów przemysłowych jak i systemów raportowania,
podstawowe znaczenie dla osiągnięcia sukcesu ma stosowanie odpowiednich metodyk
projektowania i zaangażowanie przyszłych użytkowników na każdym etapie projektu.
10