do wniosku z dnia 29 marca 2018 roku o przeprowadzenie ...€¦ · Doktor nauk technicznych w...

Załącznik nr 2

do wniosku z dnia 29 marca 2018 roku o przeprowadzenie postępowania habilitacyjnego

Autoreferat w języku polskim

Rafał Cupek - zał. 2 autoreferat w języku polskim 2

1. Imię i nazwisko:

Rafał Cupek

2. Posiadane dyplomy i stopnie naukowe:

Doktor nauk technicznych w dyscyplinie naukowej informatyka

Wydział Automatyki, Elektroniki i Informatyki, Politechniki Śląskiej, temat rozprawy

doktorskiej: „Metody wizualizacji rozproszonych procesów przemysłowych”, promotor: prof.

dr hab. inż. Andrzej Grzywak, recenzenci: prof. dr hab. inż. Krzysztof Zieliński, prof. dr hab.

inż. Antoni Niederliński, 1998.

Magister inżynier informatyk

Wydział Automatyki, Elektroniki i Informatyki Politechniki Śląskiej; specjalność: budowa

i oprogramowanie maszyn matematycznych, promotor: dr inż. Andrzej Kwiecień, 1991.

3. Przebieg zatrudnienia w jednostkach naukowych:

1991 – nadal: Politechnika Śląska, Instytut Informatyki - stanowiska:

o asystent (1991–1998),

o adiunkt (1998-2014),

o asystent /naukowy/ (2014 – nadal).

Politechnika Śląska, Wydział Automatyki, Elektroniki i Informatyki - pełnione funkcje:

o Prodziekan ds. Studenckich (2008-2012),

o Prodziekan ds. Organizacji i Rozwoju (2012-2013).

Politechnika Śląska - oddelegowanie w ramach współpracy z przemysłem:

o 24 miesiące w okresie 2014-2017, firma: Conti Temic microelectronic GmbH,

Ingolstad, Niemcy.

2002 - 2009: Wyższa Szkoła Biznesu w Dąbrowie Górniczej, stanowisko: adiunkt.

2008-2009: Technische Hochschule Ingolstadt, Niemcy, Wydział Elektrotechniki

i Informatyki, stanowisko: wykładowca (niem. Lehrbeauftragter), wymiar: 120 godzin,

przedmiot: „Industrial Computer Systems”.


4. Wskazanie osiągnięcia naukowego

wynikającego z art. 16 ust. 2 ustawy z dnia 14 marca 2003 r. o stopniach naukowych i tytule

naukowym oraz o stopniach i tytule w zakresie sztuki (Dz. U. 2016 r. poz. 882 ze zm. w Dz. U.

z 2016 r. poz. 1311.)

a) Cykl publikacji powiązanych tematycznie pod tytułem: Metody akwizycji informacji

i budowania wiedzy w systemach realizacji produkcji

[RC1] Cupek, R., Ziebinski, A., Huczala, L., & Erdogan, H., 2016, Agent-based

manufacturing execution systems for short-series production scheduling, Computers in

Industry, Elsevier, Volume 82, pp.245-258. /IF=2.691, 35 pkt. MNiSW/. Mój udział

procentowy w pracy szacuję na 60%.

[RC2] Cupek, R., Fojcik, M., & Sande, O, 2009, Object oriented vertical communication

in distributed industrial systems, Communications in Computer and Information Science book

series CCIS, Springer, volume 39, p. 72-78. / WoS; Scopus, 7 pkt. MNiSW/. Mój udział


[RC3] Cupek, R., Ziebinski, A., Drewniak, M., 2017, An OPC UA server as a gateway that

shares CAN network data and engineering knowledge, In Industrial Technology (ICIT), 2017

IEEE International Conference on, IEEE Xplore, pp. 1424-1429. /WoS; Scopus, 15 pkt.

MNiSW/. Mój udział procentowy w pracy szacuję na 60%.

[RC4] Cupek R., Ziebinski A., Fojcik M., 2017, An ontology model for communicating

with an autonomous mobile platform, Communications in Computer and Information Science

book series CCIS, Springer, volume 716, pp. 480-493. /WoS; Scopus, 15 pkt. MNiSW/. Mój

udział procentowy w pracy szacuję na 50%.

[RC5] Maka, A., Cupek, R., Rosner, J., 2011, OPC UA object oriented model for public

transportation system, In Computer Modeling and Simulation (EMS), 2011 Fifth UKSim

European Symposium on, IEEE Xplore, pp. 311-316. /Scopus; Web of Science/. Mój udział


[RC6] Cupek, R., Ziebinski, A., Franek, M., 2013, FPGA based OPC UA embedded

industrial data server implementation, Journal of Circuits, Systems and Computers, Volume

22, Issue 08, pp. 1-18. /IF=0.33, 15 pkt. MNiSW/. Mój udział procentowy w pracy szacuję na

40%.

[RC7] Cupek, R., Huczala, L., Passive PROFINET I/O OPC DA Server, In Emerging

Technologies & Factory Automation, 2009. ETFA 2009. IEEE Conference on, IEEE Xplore,

pp.1-5. / oS; Scopus, 7 pkt. MNiSW/. Mój udział procentowy w pracy szacuję na 60%.


[RC8] Cupek R., Folkert K., Fojcik M., Klopot T., Polaków G., 2017, Performance

evaluation of redundant OPC UA architecture for process control, Transactions of the

Institute of Measurement and Control,/ SAGE Journals, Vol 39, Issue 3, pp. 334-343.

/IF=1.049, 20 pkt. MNiSW/. Mój udział procentowy w pracy szacuję na 60%.

[RC9] Cupek, R., Drewniak, M., & Zonenberg, D, 2014, Online energy efficiency

assessment in serial production-statistical and data mining approaches, Proceedings of the

IEEE International Symposium on Industrial Electronics (ISIE 2014), pp. 189-194. / WoS;

Scopus, 15 pkt. MNiSW/. Mój udział procentowy w pracy szacuję na 60%.

[RC10] Cupek R., Ziebinski A., Zonenberg D., Drewniak M., 2017, Determination of the

machine energy consumption profiles in the mass-customised manufacturing, International

Journal of Computer Integrated Manufacturing, Taylor & Francis, pp.1-25. /IF=1.949, 25 pkt.

MNiSW/. Mój udział procentowy w pracy szacuję na 60%.

[RC11] Cupek R., Ziebinski A., Drewniak M., Fojcik M., 2018, Improving KPI based

performance analysis in discrete, multi-variant production, Lecture Notes in Computer

Science book series LNCS, Springer, volume 10752, pp. 661-673. Mój udział procentowy

w pracy szacuję na 70%.

[Patent] Ziębiński A., Cupek, R., Patent wydany przez Urząd Patentowy Rzeczypospolitej

Polskiej PL225022 z dn. 05.09.2016, Układ do podziału zadań realizowanych przez sterownik

PLC pomiędzy jednostkę centralną PLC i specjalizowany koprocesor sterownika PLC

zrealizowany na bazie układu reprogramowalnego. /25 pkt. MNiSW /. Mój udział procentowy

w pracy szacuję na 50%.

Cztery prace wchodzące w skład cyklu [RC1, RC6, RC8, RC10] zostały opublikowane

w czasopismach indeksowanych w bazie Journal Citation Reports (JCR), sumaryczny impact

factor tych publikacji wynosi: IF=6.019. Sześć prac to publikacje konferencyjne uwzględnione

w bazie Web of Science / Core Collection [RC2, RC3, RC4, RC5, RC7, RC9]. Publikacja

[RC11] ukazała się w serii wydawnictwa Springer - Lecture Notes in Computer Science, lecz

w chwili składania wniosku nie była jeszcze zindeksowana w WoS. Zestawienie tabelaryczne

publikacji wraz z liczbą cytowań przedstawiam poniżej.

Indeks Hirscha prac wchodzących w skład osiągnięcia według WoS / Core Collection

wynosi 4(3)*. Wartość ta nie uwzględnia cytowań w publikacjach konferencyjnych, które

w poprzednich latach były indeksowane w WoS, lecz na chwilę obecną nie są jeszcze widoczne.

Z tego względu podałem także liczbę cytowań według bazy Scopus, dla której indeks H wynosi

6(4)*. Sumaryczna liczba punktów MNSW to 186. Pięć z przedstawionych publikacji powstało

w wyniku prowadzonych przeze mnie badań przemysłowych związanych z realizacją dwóch


grantów objętych 7 Programem Ramowym: AutoUniMo1 [RC1, RC3, RC4, RC10] i EMC22

[RC9]. Publikacja [RC11] prezentuje wyniki prac, które prowadzę w projekcie INNOMOTO3.

Zestawienie tabelaryczne publikacji wchodzących w skład cyklu wraz z liczbą cytowań na

dzień 29.03.2018.

Rok

wydania

Impact

Factor

Punkty

MNSW

Liczba

Cytowań

WoS*

Liczba

Cytowań

Scopus*

[RC1] 2016 2,691 35 7(5) 11(7)

[RC2] 2009 - 7 12(4) 12(4)

[RC3] 2017 - 15 0(0) 0(0)

[RC4] 2017 - 15 2(2) 6(4)

[RC5] 2011 - 7 3(3) 9(6)

[RC6] 2013 0,33 15 5(2) 9(6)

[RC7] 2009 - 7 4(0) 8(1)

[RC8] 2017 1,049 20 2(1) 1(1)

[RC9] 2014 - 15 1(1) 4(3)

[RC10] 2017 1,949 25 - 2(0)

[RC11] 2018 - - - 1(0)

[Patent] 2016 25 - -

Razem 6,019 186 36(18) 63(32)

1 AutoUniMo (FP7-PEOPLE-2013-IAPP, grant no.: 612207) “Automotive Production Engineering Unified

Perspective based on Data Mining Methods and Virtual Factory Model”, Instytut Informatyki, Politechnika Śląska,

okres realizacji: 2013-2017

2 EMC2 (FP7-2011-NMP-ICT-FoF, Project ID: 285363) “The Eco-Factory: cleaner and more resource-

efficient production in manufacturing”, AIUT Sp. z o. o., Gliwice , okres realizacji: 2012-2014

3 INNOMOTO (NCBR POIR.01.02.00-00-0307/16-00) „Knowledge integrating shop floor management

system supporting preventive and predictive maintenance services for automotive polymorphic production

framework”, AIUT Sp. z o. o., okres realizacji: 2017 – 2020

* w nawiasie podano liczbę cytowań bez autocytowań


b) Omówienie celu naukowego wyżej wymienionych prac i osiągniętych wyników wraz z

przedstawieniem ich ewentualnego wykorzystania.

4.b.1 Streszczenie stanu wiedzy w zakresie osiągnięcia naukowego

Systemy realizacji produkcji MES (ang. Manufacturing Execution Systems) to systemy

informatyczne wykorzystywane w przemyśle, których zadaniem jest zapewnienie współpracy

pomiędzy przemysłowymi systemami sterowania a systemami wspomagającymi zarządzanie

przedsiębiorstwem. Cechy odróżniające systemy MES od innych systemów informatycznych

stosowanych w przemyśle to: (i) realizowana w czasie rzeczywistym i w sposób ciągły

komunikacja z poziomem produkcji, (ii) dokonywana na bieżąco konwersja modeli

informacyjnych, (iii) przekształcanie informacji generowanych przez systemy zarządzania do

postaci dogodnej do interpretacji przez przemysłowe systemy sterowania, (iiii) przekształcanie

i agregacja danych pobieranych z systemów sterowania do postaci, która może być

wykorzystywana przez systemy zarządzania. Systemy MES nie są jedynie interfejsem

służącym do wymiany informacji. Pomimo że systemy MES zbierają i przechowują informacje,

nie są one również repozytorium danych produkcyjnych. Systemy MES są zawansowanymi

rozwiązaniami informatycznymi, które dostarczają narzędzi pozwalających na dopasowanie

różnorodnych modeli informacyjnych wykorzystywanych w przemyśle oraz zapewniają

realizację usług umożliwiających przekształcanie surowych danych produkcyjnych

w informacje istotne dla operacyjnego zarządzania przedsiębiorstwem.

Systemy realizacji produkcji stanowią rozwinięcie powstałej w drugiej połowie lat 70.XX

wieku idei integracji przemysłowych systemów komputerowych określanej jako CIM (ang.

Computer Integrated Manufacturing). Zaproponowany przez Josepha Harringtona [1] model

CIM miał połączyć ze sobą odrębne systemy informatyczne takie jak: systemy wspomagające

projektowanie i optymalizację automatyki procesowej, systemy wspomagające planowanie

i kontrolę realizacji produkcji, systemy przygotowania i optymalizacji procesów

produkcyjnych, systemy logistyczne, systemy obsługi sprzedaży i inne. CIM miał integrować

przetwarzanie informacji w skali całego przedsiębiorstwa, jak również zapewnić współpracę

pomiędzy systemami wykorzystywanymi do jego zarządzania i komputerowymi systemami

sterowania [2]. Zadanie to wymagało zastosowania konfigurowalnej i uniwersalnej warstwy

komunikacji, która pozwoliłaby na połączenie nie tylko wielu różnorodnych systemów

informatycznych, ale także na konwersję informacji definiowanej i przetwarzanej

w oddzielnych domenach [3]. Realizacja takiego środowiska była limitowana dostępnością

technologii informatycznych i dopiero dalszy rozwój w zakresie architektury i oprogramowania

systemów rozproszonych, obiektowo zorientowanych mechanizmów komunikacyjnych

i bazujących na ontologiach modeli prezentacji informacji, pozwoliły na stworzenie otwartych,

modularnych, konfigurowalnych i zarządzalnych systemów tej klasy.


Zaproponowany przez Michaela McClellana termin Manufacturing Execution System

(MES) oznaczał działający on-line, zintegrowany system komputerowy wykorzystywany do

realizacji produkcji [4]. System MES stanowi interfejs łączący przemysłowe systemy

sterowania, w tym systemy sterowania nadrzędnego, z systemami wspomagającymi

zarządzanie przedsiębiorstwem i systemami analityki biznesowej. Słowo realizacja nawiązuje

do całości działań związanych z wykonywaniem przez przedsiębiorstwo operacji

produkcyjnych. Systemy MES zapewniają kompleksowość działań, łącząc w sobie różnego

typu narzędzia i metody a synergia wynikająca ze współdziałania sprawia, że wartość dodana

związana z optymalizacją produkcji jest większa niż ta, która wynikałaby z sumy wartości

wnoszonych przez poszczególne podsystemy [5]. Systemy MES muszą współpracować

z wieloma różnorodnymi systemami informatycznymi tak wewnątrz, jak i na zewnątrz

przedsiębiorstwa, tak więc musi je cechować otwartość i elastyczność [6].

Systemy realizacji produkcji łączą dwie odmienne pod względem funkcjonalnym

i architektonicznym klasy systemów informatycznych stosowanych w przemyśle: przemysłowe

systemy sterowania i systemy zarządzania. Te dwie klasy systemów powstały z myślą

o realizacji odmiennych zadań i z tego powodu różnią się ze względu na stosowaną do ich

realizacji architekturę informatyczną, mechanizmy komunikacji oraz podejście związane

z realizacją oprogramowania. Systemy te rozwijały się w sposób niezależny, a potrzeba ich

integracji została dostrzeżona w chwili, gdy obie dziedziny były już silnie ukształtowane. Ze

względu na trwający wiele lat, a w niektórych przypadkach wiele dziesięcioleci, cykl życia

instalacji przemysłowych, współczesne systemy realizacji produkcji muszą uwzględniać

ograniczenia architektoniczne wynikające z uwarunkowań historycznych, które kształtowały

rozwój systemów informatycznych stosowanych w przemyśle [7].

W przypadku systemów produkcji dyskretnej zawodne i trudne do modyfikacji

przekaźnikowe szafy sterownicze zostały zastąpione przez rozwiązania bazujące na

minikomputerach. Nowy rodzaj systemów sterowania został po raz pierwszy zastosowany

w przemyśle motoryzacyjnym, a następnie stał się on powszechnie stosowany także w innych

gałęziach przemysłu. Za datę przełomową przyjmuje się rok 1969, w którym firma Modicon

(nazwa została utworzona od MOdular DIgital CONtroller) uruchomiła pierwszy sterownik

PLC (ang. Programmable Logic Controller), który został zainstalowany na linii montażu

automatycznej skrzyni biegów GM Hydramatic [8]. Architektura PLC różni się znacząco od

architektury istniejących w tym czasie minikomputerów [9]. PLC były dedykowane do

interakcji z maszyną, podczas gdy minikomputery projektowane były do komunikacji

z człowiekiem. Miejsce klawiatury minikomputera zastąpiły moduły wejściowe PLC

odpowiedzialne za wprowadzanie dostarczanych za pomocą sygnałów elektrycznych

informacji opisujących stan kontrolowanej maszyny. Monitor został zastąpiony przez sygnały

wyjściowe pozwalające na sterowanie obwodami wykonawczymi. Kolejną różnicą był sposób

programowania, który został zaczerpnięty wprost z logiki realizowanej za pomocą układów


przekaźnikowych [10]. System operacyjny PLC realizuje powtarzalną cyklicznie pętlę

sterowania, w trakcie której informacje pobierane z czujników stają się danymi wejściowymi

algorytmu sterowania realizowanego przez PLC. Wypracowywane sygnały sterujące są

przekazywane do urządzeń wykonawczych. PLC zwiększyły niezawodność i ułatwiły rozwój

systemów sterowania oraz pozwoliły na zwiększenie powtarzalności realizowanych procesów

technologicznych. Cechy te były wysoce pożądane w produkcji masowej i zadecydowały

o powszechnym zastosowaniu systemów opartych o PLC w większości obszarów produkcji

dyskretnej. Architektura i oprogramowanie systemów sterowania opartych na PLC zostały

znormalizowane przez standard IEC 61131 „Programmable controllers” a w przypadku

systemów tworzonych w architekturze bazującej na komponentach przez standard IEC 61499

„Function blocks”.

W przypadku produkcji ciągłej pierwszym obszarem, w którym wprowadzono bazujące na

komputerach systemy sterowania był przemysł petrochemiczny. Systemy te miały zastąpić

regulatory pneumatyczne. Pierwsze pomysły dotyczące zastosowania komputerów do

sterowania procesami ciągłymi pojawiły się już w latach 40.XX wieku, jednak wprowadzane

w początkowym okresie minikomputery wykorzystywano jedynie do rejestracji danych,

alarmowania i kalkulacji efektywności produkcji. Samo sterowanie procesami

technologicznymi odbywało się za pomocą regulatorów pneumatycznych. Za datę

przełomową przyjmowany jest rok 1959, kiedy to firma Ramo-Wooldridge Company

uruchomiła pierwszy system komputerowy RW-300 [11], który realizował zamkniętą pętlę

regulacji. Pierwsze wdrożenie systemu RW-300 przeprowadzono w instalacji polimeryzacji

katalitycznej w rafinerii Texaco w Port Arthur. Dane wejściowe zawierały 26 pomiarów

przepływu, 72 pomiary temperatury i dwa pomiary ciśnienia. Informacje te były konwertowane

na postać cyfrową. Realizowany przez komputer model matematyczny zawierał sześć

obwodów regulacji. Część z sygnałów wyjściowych przekształcana była wprost na sygnały

sterujące pracą zaworów. Pozostałe informacje wypracowane przez komputer wykorzystywano

jako nastawy układów regulacji pneumatycznej. Ta druga część rozwiązania stała się

prekursorem systemów sterowania nadrzędnego (ang. supervisory process control).

Kolejnym etapem rozwoju systemów sterowania było wprowadzenie architektury

rozproszonej DCS (ang. Distributed Control System), którą łatwiej można dopasować do

topologii instalacji oraz uzyskać autonomię poszczególnych obwodów sterowania. Pozwoliło

to zarówno na zmniejszenie kosztów okablowania, jak również na zwiększenie niezawodności

systemu wynikającej z decentralizacji i redundancji. Za pierwszy rozproszony, cyfrowy system

sterowania DCS uważa się zaprezentowane w 1975 roku przez firmę Honeywell rozwiązanie

TDC 2000 [12]. System ten bazował na połączonych ze sobą mikroprocesorowych układach

regulacji, które zastąpiły centralny minikomputer. Pojedyncza jednostka sterująca potrafiła

kontrolować pracę ośmiu obwodów regulacji i obsługiwała do 16 sygnałów wejściowych.

Synchronizację i komunikację pomiędzy jednostkami zapewniała cyfrowa magistrala


komunikacyjna „Data Hiway” o prędkości transmisji 250 kb/s. Komunikacja z operatorami

realizowana była za pomocą minikomputera wyposażonego w klawiatury i monitory CRT.

Minikomputer był także wykorzystywany do realizacji sterowania nadrzędnego. Obecnie

rozwiązania stosowane w sieciach komunikacyjnych łączących rozproszone systemy

sterowania (ang. field bus) normalizowane są poprzez standard IEC 61158 „Industrial

communication”, a sposoby wykorzystania tych sieci określane są przez standard IEC 61784

„Industrial communication networks - Profiles”.

Historia zastosowania komputerów w systemach zarządzania sięga lat 60.XX stulecia.

Wprowadzenie nowych środków technicznych traktowano jako usprawnienie procedur

wykonywanych wcześniej w sposób manualny [13]. Przykładem wczesnych rozwiązań są

systemy ROP (ang. reorder point), których zadaniem było sprawdzanie stanów magazynowych

i w przypadku osiągnięcia minimalnego poziomu generowanie zamówień uzupełniających.

W systemach planowania i kontroli produkcji MPC (ang. manufacturing planning and control)

komputer wykorzystywano jako narzędzie do zapisu zamówień na taśmach magnetycznych lub

kartach perforowanych. Taśmy były wielokrotnie przeglądane i na tej podstawie tworzono listę

potrzebnych materiałów BOM (ang. bills of materials). Kompletny system komputerowy

składał się z wielu oddzielonych od siebie jednostek (ang. frame). Terminem mainframe

określano główną jednostkę przetwarzającą dane. Początkowo oprogramowanie komputerów

mainframe przygotowano indywidualnie zgodnie z architekturą komputera i modelem

biznesowym przedsiębiorstwa.

Na początku lat 70 XX pojawił się nowy rodzaj oprogramowania - systemy planowania

zapotrzebowania materiałowego MRP (ang. Material Requirements Planning). Podczas

zorganizowanej w 1971 roku w St. Louis 14 konferencji APICS (American Production and

Inventory Control Society) Joseph Orlicky zaprezentował pracę „MRP – A hope for the future

or a present reality – a case study”, która zapoczątkowała dyskusję pomiędzy zwolennikami

klasycznych modeli zarządzania przedsiębiorstwem takimi jak np. ROP a nowym sposobem

zarządzania opartym o MRP. System MRP dostarczał mechanizmów, które pozwalały firmom

produkcyjnym dokładniej zaplanować jakie materiały i w jakim czasie będą im potrzebne.

Bezpośrednią korzyścią zastosowania systemów MRP była optymalizacja zasobów

magazynowych. Kolejnym etapem rozwoju były systemy planowania produkcji MRP II (ang.

Manufacturing Resource Planning). Występująca w akronimie cyfra II została dodana dla

odróżnienia tych systemów od MRP, które wykorzystywano do planowania zamówień.

Kolejną różnicą jest praca systemów MRP II w pętli sprzężenia zwrotnego. Decyzje biznesowe

przekładają się na działania produkcyjne, z kolei wyniki działań produkcyjnych mogą wymagać

korygujących operacji po stronie systemów zarządzania. Wprowadzanie nowych rozwiązań

informatycznych w tym relacyjnych baz danych, języków czwartej generacji, wykorzystanie

narzędzi wspomagania komputerowego do konstruowania systemów i architektury


klient/serwer doprowadziło do powstania nowej generacji systemów wspomagających

zarządzanie określanych jako ERP (ang. Enterprise Resource Planning) [14].

Z biegiem czasu coraz silniej widoczna była potrzeba integracji systemów informatycznych

wykorzystywanych w przemyśle. Integracja ta może być rozpatrywana w trzech płaszczyznach:

jako integracja pionowa pozioma i integracja technologii informatycznych [15]. Potrzeba

integracji pionowej wynikła z konieczności przekazywania coraz dokładniejszych informacji

na temat realizowanych procesów produkcyjnych pomiędzy systemami sterowania a systemami

zarządzania. Początkowo informacje te wymieniane były w sposób ręczny, a nośnikiem

informacji był personel przedsiębiorstwa. Wraz ze zwiększaniem się wolumenu informacji

i skracaniem czasu cyklu planowania konieczna stała się automatyzacja wymiany danych. Pod

pojęciem integracji poziomej kryje się wymiana informacji pomiędzy systemami

umieszczonymi na tym samym (pod względem funkcjonalnym) poziomie. Przykładem może

być synchronizacja pomiędzy poszczególnymi maszynami, z których każda wyposażona jest

w własny system sterowania czy też wymiana informacji w systemach sterowania

nadrzędnego. Trzeci aspekt integracji wiąże się z cyklem życia systemów informatyki

przemysłowej. Dla wielu systemów informatycznych czas życia jest porównywalny z okresem

funkcjonowania fizycznych urządzeń produkcyjnych. Prowadzi to do sytuacji, gdy muszą ze

sobą współpracować rozwiązania reprezentujące zupełnie różny poziom rozwoju technologii

informatycznych. Z jednej strony konieczność ciągłego udoskonalania procesu produkcji

wymusza wprowadzanie nowych rozwiązań, z drugiej strony konieczność utrzymania ciągłości

produkcji nie pozwala na ich kompleksową modernizację.

Aby uporządkować sposób opisu systemów informatyki przemysłowej oraz ułatwić

integrację poszczególnych systemów, wprowadzono w latach 90.XX wieku model o wysokim

poziomie abstrakcji, który nazywany jest piramidą automatyzacji (ang. automation piramid)

[16]. Całość stosowanych przez przemysł rozwiązań informatycznych umieszczana jest

w poszczególnych warstwach piramidy przy zachowaniu zasady: im niższa warstwa piramidy

tym system znajduje się bliżej fizycznych procesów produkcyjnych, im wyższa warstwa

piramidy tym system znajduje się bliżej procesów zarządzania. Podstawę piramidy stanowi

rzeczywisty proces produkcyjny, kolejne warstwy odpowiadają gromadzeniu łączeniu

i przekształcaniu informacji pochodzącej z obiektu, wreszcie wierzchołek piramidy

odzwierciedla informacje wykorzystywane przez systemy zarządzania. Model ten definiuje nie

tylko strukturę informatyczną, ale także strukturę organizacyjną przedsiębiorstwa, w którym

decyzje biznesowe związane z realizacją konkretnego zamówienia przechodzą od poziomu

zarządzania biznesowego poprzez kolejne szczeble zarządzania operacyjnego do poziomu

realizacji operacji. W drugą stronę przekazywane są informacje o postępie w realizacji

zleconych zadań produkcyjnych. Informacje opisujące zarówno produkt, jak i proces

przemysłowy związany z jego wytworzeniem poddawane są obróbce i agregacji, a następnie

przekazywane w górę piramidy, gdzie docierają w końcu jako raport z realizacji produkcji do


szczebla zarządzania. Przedstawiony przez Tilo Sautera model [17] definiuje pięć warstw

piramidy automatyzacji: 0 – Czujniki i urządzenia wykonawcze, 1 – Przemysłowe systemy

sterowania, 2 - Systemy wizualizacji i sterowania nadrzędnego, 3 - Systemy realizacji

produkcji, 4 - Systemy wspomagające zarządzanie (Rys.1).

Model piramidy automatyzacji stosowany jest do opisu heterogenicznych systemów

informatyki przemysłowej. Pozwala on na uproszczenie opisu systemu informatycznego

o wielu zastosowaniach i wysokim stopniu złożoności, w którego skład wchodzą zarówno

proste wejścia/wyjścia, sterowniki PLC, komputery przemysłowe, złożone układy DCS, stacje

kontrolno-nadzorcze klasy SCADA (ang. Supervisory Control and Data Acquisition),

przemysłowe bazy danych, systemy realizacji produkcji MES czy wreszcie systemy

wykorzystywane w zarządzaniu przedsiębiorstwem klasy ERP (ang. Enterprise Resource

Planning). Model piramidy pozwala na odróżnienie zadań komunikacji poziomej od pionowej.

Komunikacja pozioma obejmuje te usługi wymiany danych, w których odbiorca i dostawca

informacji zlokalizowani są w tej samej warstwie piramidy. Natomiast w komunikacji pionowej

dostawca i odbiorca informacji znajdują się na różnych poziomach. W modelu klasycznym oba

typy komunikacji rozpatrywane są oddzielnie i realizowane za pomocą odmiennych

protokołów komunikacyjnych. Wprowadzenie nowych rozwiązań telekomunikacyjnych, jak

np. protokołu OPC UA zapoczątkowało prace nad połączenie obu rodzajów komunikacji [15].

Rys. 1. Model piramidy automatyzacji

W przedstawionym modelu systemy realizacji produkcji MES pełnią funkcję interfejsu

umożliwiającego komunikację pomiędzy systemami sterowania i zarządzania. Pozwalają one

zarówno na wymianę danych, jak i zapewniają odpowiednią konwersję formatów reprezentacji


informacji. Systemy realizacji produkcji wspomagają zarządzanie operacyjne produkcją

podczas gdy systemy zarządzania koncentrują się na działaniach biznesowych. Decyzje

podejmowane na poziomie systemów zarządzania muszą przekładać się na działania

produkcyjne zmierzające do realizacji zadań biznesowych przedsiębiorstwa. W takim

kontekście systemy MES stanowią przedłużenie systemów zarządzania. Ich zadaniem jest

rozdzielenie i nadzorowanie realizacji zadań produkcyjnych, a także zbieranie informacji na

temat sposobu wykonania zadań produkcyjnych. Systemy realizacji produkcji muszą także

współpracować z systemami planowania, wspomagając przygotowanie produkcji

z uwzględnieniem planowania sekwencji zleceń przekazywanych do poszczególnych

podsystemów produkcyjnych, kontrolować wykorzystanie zasobów produkcyjnych, zbierać

szczegółowe informacje na temat poszczególnych etapów realizacji produkcji, kontrolować

i zarządzać ruchem materiałów, półproduktów i wyrobów finalnych [16].

W chwili obecnej systemy MES stoją przed nowymi wyzwaniami, które związane są ze

zmianą modelu biznesowego zdecydowanej większości przedsiębiorstw [18]. Są to: skracanie

serii produkcyjnej, indywidualizacja produktu, dostawy w czasie produkcji (ang. just in time

manufacturing), szczupła produkcja (ang. lean manufacturing) czy funkcjonowanie

przedsiębiorstwa w ramach łańcucha usług, w którym przedsiębiorstwo pełni zarówno funkcję

konsumenta, jak i dostawcy usług [19]. Zmiany w modelu biznesowym pociągają za sobą

konieczność dopasowania architektury systemów realizacji produkcji i modelu realizacji usług

[20]. Połączone w łańcuch przedsiębiorstwa muszą bazować na wysoce spersonalizowanych

produktach i usługach, które są dostarczane przez inteligentne, zautomatyzowane i

zintegrowane narzędzia. Wymaga to uporządkowania modelu informacyjnego, który można

osiągnąć poprzez wspólną reprezentację semantyczną opisywaną za pomocą ontologii

definiowanych z wykorzystaniem narzędzi informatycznych jak np. Web Ontology Language

(OWL) [21]. Architektury informatyczne bazujące na modelach MDA (ang. Model Driven

Architecture) umożliwiają oddzielenie opisu przedsiębiorstwa od infrastruktury

technologicznej i rozdzielenie funkcji biznesowych od sposobu ich implementacji [22].

Zmiany w architekturze informatycznej umożliwiają wykorzystanie systemów MES jako

narzędzia współpracy na poziomie operacyjnego zarządzania realizacją produkcji i integracji

poziomej współpracujących przedsiębiorstw [23].

Systemy realizacji produkcji coraz powszechniej korzystają z nowych technologii

informatycznych takich jak komunikacja i identyfikacja bezprzewodowa RFID [24,25], Internet

rzeczy (IoT Internet of Things) [26] czy chmura obliczeniowa (Cloud Computing) [27].

Informacja opisująca zarówno sam produkt oraz przebieg procesu produkcyjnego staje się

z jednej strony coraz bardziej precyzyjna [28], z drugiej strony ogromny wolumen

przetwarzanych danych utrudnia ich właściwą interpretację. Zastosowanie nowych rozwiązań

informatycznych w zakresie sprzętu, nowych metod komunikacji czy zaawansowanych

algorytmów eksploracji danych pozwala na zwiększenie elastyczności przedsiębiorstw


pozwalającej na dopasowanie profilu i sposobu realizacji produkcji do wymagań rynku.

Umożliwia to bardziej efektywną współpracę przedsiębiorstw, które wprowadzają nowe

modele wytwarzania w ramach łańcucha produkcji.

Opisane powyżej zmiany znajdują się w centrum zainteresowania zarówno przedsiębiorstw

produkcyjnych, dostawców technologii produkcyjnych, jak i wspieranych przez organizacje

rządowe grup doradczych takich jak niemiecka Industry 4.0, powiązana z departamentem

handlu USA instytut NIST (ang. National Institute of Standards and Technology) czy SMLC

(Smart Manufacturing Leadership Coalition) działające w Korei Południowej stowarzyszenie

[29]. Zaproponowany przez NIST program „Smart Manufacturing Operations Planning and

Control” definiuje inteligentną produkcję (ang. smart manufacturing) jako wprowadzenie

w pełni zintegrowanych i opartych na współpracy systemów produkcyjnych, reagujących

w czasie rzeczywistym, aby sprostać zmieniającym się wymaganiom i warunkom

w przedsiębiorstwie. Systemy te pozwalają na współpracę w modelu łańcucha usług oraz na

realizację indywidualnych potrzeb klientów4.

Jednym z powszechnie używanych terminów opisujących zachodzące obecnie zmiany jest

określenie „czwarta rewolucja przemysłowa”. Pojęcie czwartej rewolucji przemysłowej

używane jest w odniesieniu do ogólnej koncepcji związanej z zastosowaniem systemów

cyberfizycznych CPS w przemyśle [30]. Rainer Drath i Alexander Horch w pracy “Industrie 4.0:

Hit or Hype?” [31] zwracają uwagę na fakt, że o ile trzy pierwsze rewolucje przemysłowe

zostały zidentyfikowane i nazwane z perspektywy historycznej, to termin czwarta rewolucja

przemysłowa pojawił się z wyprzedzeniem jako zapowiedź spodziewanych w przyszłości

zmian. Pomimo dostępności nowych technologii informatycznych i licznych korzyści

wynikających z ich zastosowania w przemyśle, ocena ich wpływu zmianę metod realizacji

produkcji pozostaje kwestią przyszłości.

Na tle przedstawionego powyżej stanu wiedzy rodzi się szereg wyzwań związanych

z dalszym rozwojem rozwiązań informatycznych stosowanych w systemach realizacji

produkcji. Przedstawione w osiągnięciu prace odnoszą się do następujących problemów:

Zdecydowana większość rozwiązań informatycznych wykorzystywanych w systemach

MES bazuje na architekturze scentralizowanej. Poszczególne aplikacje realizują określone

założenia funkcjonalne, dostarczają usług i pobierają dane z innych, także

scentralizowanych aplikacji. Struktura usług i model komunikacji są sztywno określane na

etapie tworzenia tych systemów. Każdorazowa zmiana w zakresie modelu biznesowego lub

modyfikacja warstwy sterowania wymaga modyfikacji oprogramowania systemów MES.

Zmiany wprowadzone w jednej części systemu mogą pociągać konieczność przebudowy

4 National Institute of Standard and Technology, “Smart Manufacturing Operations Planning and Control,”

http://www.nist.gov/el/msid/syseng/upload/FY2014_SMOPAC_ProgramPlan.pdf, [28.03.18]

http://www.nist.gov/el/msid/syseng/upload/FY2014_SMOPAC_ProgramPlan.pdf


innych części. Istniejący model architektoniczny cechuje się brakiem elastyczności.

Z jednej strony koszt wprowadzania zmian jest wysoki, z drugiej strony istnieje wysokie

ryzyko utraty spójności informacji i wystąpienia błędów funkcjonalnych. W pracy [RC1]

przedstawiłem architekturę informatyczną systemów MES, która charakteryzuje się wysoką

elastycznością i łatwością adaptacji systemu informatycznego do zmian w zakresie

stosowanej technologii produkcji.

W większości aktualnie stosowanych systemów realizacji produkcji zależności pomiędzy

danymi oraz usługami realizowanymi przez system zaszyte są w oprogramowaniu

aplikacyjnym. Aplikacje bazują na wiedzy inżynierskiej, która jest ukryta i niedostępna dla

innych systemów. Powyższa sytuacja sprawia, że istnieje szereg niejawnych powiązań

pomiędzy informacją pobieraną z procesu a usługami realizowanymi przez systemy

informatyczne. Ukryte powiązania i zaszyte wewnątrz aplikacji modele danych mogą

prowadzić do błędów w przypadku zmiany funkcjonalności systemu informatycznego czy

też zmian po stronie dostawców lub konsumentów danych. W pracach [RC2, RC3, RC4,

RC5] podjąłem problematykę wykorzystania pośredniczącej warstwy komunikacyjnej

(ang. comunication middleware) celem rozdzielenia modelu informacyjnego od usług

realizowanych przez wykorzystujące ten model aplikacje.

Przeniesienie nowych technologii komunikacyjnych z systemów informatycznych

ogólnego stosowania do systemów informatyki przemysłowej odbywa się często bez

analizy ograniczeń związanych ze specyfiką tych systemów i występujących w nich

zależności oraz ograniczeń. Powoduje to liczne problemy związane z zastosowaniem

nowych technologii informacyjnych i telekomunikacyjnych w systemach MES. W pracach

[RC6, RC7, RC8, patent] przedstawiłem wyniki badań nad opartymi o protokół OPC UA

rozwiązaniami komunikacyjnymi, które zapewniają efektywną i niezawodną komunikację

wykorzystywaną w systemach realizacji produkcji.

Systemy informatyczne wykorzystywane w przemyśle operują na coraz większym

wolumenie danych. Dane te jednak wykorzystywane są jedynie w niewielkim stopniu.

Informacja tworzona dla specyficznych potrzeb związanych z realizacją określonych usług

informatycznych nie jest wykorzystywana w innych dziedzinach. Prowadzi to z jednej

strony do powielania informacji oraz utraty spójności. W pracach [RC9, RC10, RC11]

przedstawiłem wyniki badań mających na celu automatyczne tworzenie profili

energetycznych stacji produkcyjnych z wykorzystaniem danych dostępnych w systemach

sterowania.

W dalszej części autoreferatu przedstawiłem swój wkład w analizowaną dziedzinę oraz

opisałem wyniki badań, które zmierzają do rozwiązania wymienionych powyżej problemów.


4b.2 Wykaz najważniejszych osiągnięć habilitanta

Osiągnięcie habilitacyjne zawiera zestawienie najważniejszych wyników badań w zakresie:

architektury systemów MES, wymiany informacji w tych systemach, modelowania danych

i konwersji modeli informacyjnych oraz zastosowania mechanizmów eksploracji danych do

analizy efektywności energetycznej stanowisk produkcyjnych. W badaniach wykorzystałem

doświadczenia, które zdobyłem w trakcie mojej współpracy z przemysłem. W trakcie

oddelegowania do firmy Continental Ingolstadt opracowałem i zrealizowałem system MES

dedykowany do wspomagania produkcji krótkoseryjnej. W ramach współpracy z firmą AIUT

Sp. z o. o. prowadziłem badania związane z analizą danych dostępnych w systemach sterowania

celem uzyskania wiedzy na temat zależności pomiędzy realizowaną technologią produkcji

a zużyciem energii przez stanowisko produkcyjne. Prowadziłem także prace nad

wykorzystaniem warstwy komunikacji pośredniej (ang. communication middleware) do

prezentacji struktury dostępnych danych, jak i występujących w nich zależności

semantycznych. Badałem problemy związane z efektywną i niezawodną komunikacją

w systemach MES, poczynając od warstwy sterowania, poprzez warstwę komunikacji na

poziomie sieci przemysłowych aż do wymiany informacji na poziomie sieci zakładowej oraz

Internetu. Opracowałem algorytmy analizy efektywności energetycznej stanowisk

produkcyjnych na podstawie danych dostępnych w systemach sterowania. Za najważniejsze,

oryginalne osiągnięcia uważam:

Opracowałem nowy model architektoniczny systemów MES dedykowanych do produkcji

krótkoseryjnej. Model ten łączy wymagania funkcjonalne stawiane dla systemów MES (na

podstawie założeń przygotowanych przez Manufacturing Enterprise Solutions

Association5) z wyzwaniami wynikającymi ze specyfiki realizacji produkcji krótkoseryjnej.

W pracy [RC1] przedstawiłem proponowaną architekturę systemu wraz z przykładami

zastosowania, które zaczerpnąłem z doświadczeń zdobytych w trakcie realizacji systemu

MES dla działu produkcji prototypów urządzeń elektroniki samochodowej firmy

Continental Ingolstadt. W czasie mojego oddelegowania do firmy Continetal Ingolstadt

kierowałem projektem informatycznym, którego efektem jest oprogramowanie

wykorzystywane do wspomagania produkcji prototypowych systemów ADAS (ang.

Advanced Driver Assistance Systems). Zaproponowałem model architektoniczny, który

bazuje na trójpoziomowej hierarchii usług i pozwala na elastyczne dopasowanie systemu

MES do zmian w realizowanej technologii produkcyjnej. Powstały na bazie modelu system

różni się od innych rozwiązań stosowanych przez Continental w zakresie: (i) rozdzielenia

logiki biznesowej od funkcji realizowanych przez system MES, (ii) elastycznego powiązania

pomiędzy systemami sterowania i zarządzania, (iii) zastosowania bazującej na modelu

5 http://www.mesa.org


agentowym warstwy pośredniej ułatwiającej dopasowanie usług informatycznych do

realizowanej technologii produkcji.

Przeprowadziłem badania związane z zastosowaniem pośredniczącej warstwy

komunikacyjnej (ang. communication middleware) do prezentacji struktury i wzajemnych

relacji pomiędzy danymi wykorzystywanymi w systemach realizacji produkcji. Dla

wybranych przypadków przedstawiłem i zweryfikowałem możliwości prezentacji

metainformacji z wykorzystaniem stosowanych w przemyśle narzędzi, które umożliwiają

realizację komunikacji zgodnie ze standardem OPC UA (IEC 62541). Zaproponowany

model pozwala na udostępnienie ukrytych zależności pomiędzy danymi i na prezentację ich

semantyki. Klienci OPC UA mają dostęp do metainformacji, które ułatwiają dobór

dogodnej postaci i formy reprezentacji danych, co zmniejsza ryzyko błędu w implementacji

systemu. Przedstawiłem przykłady, które stanowią alternatywę dla rozwiązań

wykorzystujących wbudowane w aplikacje mechanizmy interpretacji danych. W pracay

[RC2] przeprowadziłem (i) analizę możliwości zastosowania podejścia obiektowego do

prezentacji danych w systemach SCADA (ang. Supervisory Control and Data Acquisition).

W pracy [RC3] przedstawiłem analizę dla przypadku (ii) prezentacji informacji

wymienianych w sieci CAN. W pracy [RC4] zaproponowałem (iii) model komunikacji z

autonomiczną platformą mobilną w pracy [RC5] (iiii) model dla transportu publicznego.

Przeprowadziłem analizę efektywności i niezawodności komunikacji bazującej na

standardzie OPC UA realizowanej w modelu subskrypcji. Przedstawiłem wybrane

przykłady implementacji tego modelu w pośredniczącej warstwie komunikacji dla

przypadków zaczerpniętych z systemów stosowanych w przemyśle. Przedstawiłem także

wyniki badań laboratoryjnych związanych z zastosowaniem obiektowo zorientowanych

interfejsów komunikacyjnych celem zapewnienia niezawodnej i efektywnej komunikacji

pomiędzy wybranymi elementami przemysłowych systemów informatycznych.

Zaprezentowane wyniki prac obejmują: (i) realizację wbudowanych koprocesorów

komunikacyjnych [RC6, patent], (ii) bezpośrednią akwizycję danych z sieci przemysłowych

[RC7], (iii) zastosowanie redundancji celem zwiększenia niezawodności transmisji

w komunikacji pionowej [RC8].

Opracowałem metodę analizy zależności pomiędzy technologią produkcji a zużyciem

energii przez stanowisko produkcyjne, która jest niezależna od implementacji algorytmu

sterowania. Informację wejściową stanowią liczniki mediów i sygnały sterujące pracą

poszczególnych urządzeń. W ramach badań przemysłowych, które realizowałem na

potrzeby firmy AIUT Sp. z o. o. zaproponowałem i zweryfikowałem algorytm identyfikacji

kroków produkcji dyskretnej, które są istotne ze względu na efektywność energetyczną

stanowiska produkcyjnego [RC9]. Zaproponowaną metodę rozwinąłem następnie dla

przypadku produkcji wielowariantowej. W pracy [RC10] przedstawiłem metodę analizy

profili energetycznych stanowisk realizujących wielowariantową produkcję dyskretną.

W pracy [RC11] przedstawiłem metodę automatycznej detekcji liczby wariantów


produkcyjnych, które są istotne dla analizy wybranych kluczowych wskaźników produkcji

KPI (ang. Key Performance Indicators).

4b.3 Omówienie wkładu habilitanta w zakresie rozwiązań architektonicznych

systemów MES dedykowanych dla produkcji krótkoseryjnej

W pracy [RC1] przedstawiłem model architektoniczny systemu MES, który został

dopasowany do specyfiki krótkoseryjnej produkcji dyskretnej. Rozwiązanie bazuje na

przedstawionym przez Theodora Josepha Wiliamsa modelu PURDUE [32] oraz modelach

przygotowanych przez organizację MESA6 w postaci rodziny standardów ISA95 (IEC 62264)

[33]. Przyjęte założenia architektoniczne bazują na doświadczeniach, które zdobyłem w trakcie

zrealizowanego dla firmy Continental Ingolstadt systemu wspomagającego realizację produkcji

prototypów urządzeń elektronicznych. Ze względu na specyfikę produkcji realizowanej przez

Prototyping Department, Continental Ingolstadt, zastosowanie klasycznego systemu MES,

wykorzystywanego przez inne działy firmy Continental do wielowariantowej produkcji

krótkoseryjnej nie było w tym przypadku możliwe. W klasycznych rozwiązaniach systemów

MES model jest wbudowany w system realizacji produkcji, a realizacja procesu prowadzona

jest zgodnie z regułami zaszytymi w tym systemie. W przypadku zmiany procesu

technologicznego następuje korekta algorytmów i struktur danych, co wymaga ingerencji

w oprogramowanie systemu MES. W przypadku produkcji krótkoseryjnej realizowanej przez

dział prototypów, proces produkcji musi uwzględnić specyfikę nowego urządzenia, jak i etap

rozwoju produktu, dla którego tworzony jest prototyp. Zadanie to nie może więc być

realizowane przez klasyczny systemem realizacji produkcji o sztywnej hierarchii

i predefiniowanym sposobie przepływu informacji. Nowy model oparłem o architekturę

systemu wieloagentowego o luźno powiązanych komponentach, które dostarczają usług

informatycznych związanych z realizacją produkcji. System ma architekturę heterarchiczną

i odzwierciedla rzeczywisty przepływ informacji i usługi niezbędne do realizacji produkcji

krótkoseryjnej. Rys.2 przedstawia model przepływu informacji w systemie, który prezentuje

zarządzanie operacjami produkcyjnymi obejmującymi: dostępne technologie produkcyjne,

potencjalne możliwości realizacji produkcji, planowanie zadań i realizację operacji

produkcyjnych.

Dostarczane przez agentów usługi odzwierciedlają typowe operacje realizowane

w systemach MES jak:

Zarządzanie technologią produkcji – w trakcie produkcji prototypu podejmowane są decyzje

dotyczące zmian technologii produkcyjnej, które wynikają z błędów zauważonych w czasie

6 MESA - Manufacturing Enterprise Solutions Association; www.mesa.org


produkcji lub z konieczności optymalizacji technologii produkcyjnej. Zadaniem systemu jest

śledzenie wprowadzanych zmian i wiązanie ich z przyczynami.

Rys. 2. Model zarządzania operacjami produkcyjnymi na podstawie [ISA95]

Zarządzanie zasobami – powiązanie z systemem zarządzania (SAP) pozwala na dostęp do

informacji o materiałach potrzebnych do realizacji zamówienia produkcyjnego (ang. Bil of

Materials). Zlecenie produkcyjne zawiera informacje na temat wymaganej technologii

produkcyjnej, która wymaga wykorzystywania określonych maszyn i linii produkcyjnych

a także personelu niezbędnego do realizacji produkcji oraz materiałów. Złożone procesy

produkcyjne dzielone są na mniejsze segmenty, za których realizację odpowiada pojedyncza

stacja. W produkcji prototypów zarówno lista materiałów, jak i wykorzystywana technologia

mogą ulegać zmianie w wyniku uzyskanych doświadczeń.

Szczegółowe szeregowanie zadań produkcyjnych – umożliwia ułożenie planu produkcyjnego

w krótkim horyzoncie czasowym (jedna lub kilka zmian). Sam proces szeregowania

w przypadku produkcji prototypów realizowany jest ręcznie, jednak zaproponowany w pracy

[RC1] mechanizm symulacji pozwala na oszacowanie czasu realizacji poszczególnych zleceń

i obciążenia stanowisk produkcyjnych w zależności od przyjętego wariantu realizacji

produkcji.

Rozdzielenie zadań produkcyjnych – zależy od technologii produkcji określonej w zleceniu

produkcyjnym oraz od wyniku realizacji poprzednich operacji. W produkcji prototypów nie

określa się sztywnej ścieżki produkcyjnej, ale możliwe warianty oraz ograniczenia co do np.

liczby powtórzeń kolejnych kroków czy kolejności realizacji poszczególnych operacji.


Zadaniem systemu realizacji produkcji jest wskazywanie możliwych do wykonania kolejnych

zadań oraz blokowanie operacji, które nie mogą być wykonywane na danym etapie.

Zarządzanie realizacją produkcji – polega na bezpośredniej komunikacji z urządzeniami

wykorzystywanymi w produkcji oraz z personelem odpowiedzialnym za realizację

poszczególnych operacji. Zadaniem systemu jest dostarczenie odpowiednich parametrów

procesu i wynikających z nich nastaw urządzeń, algorytmów testowania produktów, instrukcji

i procedur dla operatorów itp. Operacje te poprzedzają bezpośrednio rozpoczęcie produkcji

i realizowane są w oparciu o parametry zlecenia i wyniki realizacji poprzednich kroków.

Zbieranie danych produkcyjnych - obejmuje gromadzenie wszystkich istotnych informacji,

które opisują proces produkcji z rozbiciem na poszczególne kroki technologiczne.

Rejestrowane są: wykorzystane materiały, urządzenia i personel realizujący operacje, wyniki

realizacji operacji, rzeczywiste parametry produkcyjne, występujące błędy w produkcji czy

czas przestoju urządzeń związany ze zmianą profilu produkcji.

Śledzenie produkcji - to proces przekształcania surowych danych produkcyjnych

w informacje istotne ze względu na model biznesowy, jak i technologię produkcji. Na tym

etapie następuje agregacja informacji. Zagregowane dane mogą być wykorzystywane jako

dokumentacja procesu produkcyjnego (zrealizowana ścieżka produkcyjna), dokumentacja

produktu (rzeczywiste cechy produktu zmierzone w trakcie testów), informacje potrzebne dla

służb utrzymania ruchu (informacje o powtarzających się błędach produkcji mogą wpływać na

podejmowane działania zaradcze), informacje wykorzystywane w zarządzaniu jakością

(technologia produkcji, metodyka weryfikacji parametrów produktu, weryfikacja procedur

kontroli jakości analiza parametrów określających jakość produktu).

Analiza wydajności produkcji – w zależności od analizowanych kluczowych wskaźników

produkcji KPI (ang. Key Performance Indicators) przetwarzane są wybrane informacje

pozyskane na etapie zbierania danych. Etap analizy obejmuje kalkulację i weryfikację

kluczowych parametrów produkcji zarówno ze względu na wartości KPI zarejestrowane dla

danego produktu lub rodziny produktów, jak i ze względu na zmiany tych wartości wynikające

z zastosowania różnych wariantów technologii produkcyjnych.

Zaproponowany model architektoniczny systemu składa się z trzech zrealizowanych

w modelu usługowym warstw, które przedstawione są na rys. 3. Zewnętrzna warstwa

udostępnia usługi realizowane w systemie MES takie jak: zarządzanie zleceniami (ZZ), które

obejmuje uzgodnienie parametrów zlecenia i śledzenie postępu jego realizacji; zarządzenie

jakością (ZJ), które obejmuje analizę wpływu parametrów produkcji i wybranej technologii na

jakość produktu i błędy w czasie realizacji produkcji; zarządzanie wydajnością produkcji (ZW),

które pozwala na analizę zależności pomiędzy wybranym wariantem technologii produkcyjnej

a wydajnością i inne. Ze względu fakt, że system wykorzystywany jest przez wielu

użytkowników znajdujących się w oddalonych od siebie oddziałach firmy Continental, warstwa


zewnętrzna została zrealizowana w technologii Microsoft / MVC i dzięki temu komunikacja

użytkowników z systemem może być realizowana za pomocą przeglądarki internetowej

z dowolnego komputera zlokalizowanego w domenie przedsiębiorstwa. Dostępne interfejsy

pozwalają użytkownikom systemu na składanie nowych zleceń, komunikację z opiekunem

produktu, analizę wydajności produkcji czy kontrolę jakości.

Warstwa wewnętrzna systemu stanowi interfejs pozwalający na komunikację z systemem

sterowania i personelem produkcyjnym. Wymieniane są informacje dotyczące zużywanych

i produkowanych materiałów, wykorzystywanych stanowisk i linii produkcyjnych ze

szczegółową identyfikacją planowanych i zrealizowanych parametrów produkcji oraz

informacje na temat realizującego te zadania personelu. Warstwa wewnętrzna pozwala na

połączenie pomiędzy systemem informatycznym, a rzeczywistymi zasobami produkcyjnymi

przedsiębiorstwa. Zaproponowany model bazuje na idei holonów zaprezentowanej po raz

pierwszy przez Jamesa Christensena w pracy [34]. Holony pozwalają na tworzenie w sposób

dynamiczny reprezentacji logicznej zasobów fizycznych poprzez grupowanie i udostępnianie

informacji na temat: materiałów (HM), urządzeń (HU), personelu (HP) czy tworzonych poprzez

połączenie tych zasobów segmentów (HS). Reprezentacja za pomocą holonów pozwala na

opisywanie zależności o charakterze dynamicznym, które powstają na etapie planowania

produkcji poprzez grupowanie lub rozdzielanie zasobów. Połączenia te mogą ulegać zmianie

w trakcie realizacji produkcji. Przyjęta architektura umożliwia ukrycie szczegółów, które są

nieistotne dla systemu realizacji produkcji.

Rys. 3. Model systemu realizacji produkcji


Połączenie pomiędzy wewnętrzną i zewnętrzną warstwą systemu realizowane jest poprzez

niezależne usługi realizowane za pomocą agentów obsługujących takie zadania jak:

przygotowanie i realizacja zamówienia (AZ1, AZ2, AZ3), kontrola jakości produkcji na jej

kolejnych etapach (AJ1, AJ2) czy kontrola wydajności poszczególnych segmentów procesu

technologicznego oraz operacji realizowanych wewnątrz tych segmentów (AW). Informacje

wymieniane są za pomocą kanałów komunikacyjnych dopasowywanych do realizowanych

aktualnie zadań i wykorzystywanych obiektów biorących udział w dostarczaniu i przetwarzaniu

informacji. Środkowa warstwa systemu odpowiada także za konwersję pomiędzy modelem

prezentacji informacji wykorzystywanym na poziomie biznesowym a modelem

wykorzystywanym na poziomie fizycznej realizacji produkcji.

4b.4 Omówienie wkładu habilitanta w zakresie zastosowania pośredniczącej

warstwy komunikacyjnej do prezentacji struktury i wzajemnych relacji pomiędzy

danymi wykorzystywanymi w systemach realizacji produkcji

Konwersja modeli informacyjnych i dynamiczne budowanie kanałów komunikacyjnych

wymaga zastosowania warstwy komunikacji pośredniej (ang. communication middleware),

która dostarczy usług pozwalających na transformację danych do postaci właściwej dla

wybranego kontekstu ich wykorzystania [34]. W pracy [RC2] przedstawiłem porównanie

klasycznych mechanizmów komunikacji pionowej wykorzystujących cykliczny odczyt danych

procesowych z koncepcją bazującą na podejściu obiektowym, w której źródło informacji

udostępnia klientom możliwość subskrypcji potrzebnych informacji. Klienci wybierają

zarówno subskrybowane dane, jak i parametry związane ze śledzeniem i przekazywaniem

informacji na temat zmian ich wartości. Informacje opisywane są przez oparty o hierarchię

typów metamodel, który pozwala na prawidłową interpretację treści informacji oraz na

wyszukiwanie zależności pomiędzy danymi prezentowanymi z wykorzystaniem mechanizmu

referencji. Jednym z powszechnie akceptowanych w przemyśle standardów wymiany

i modelowania informacji jest OPC Unified Architecture [36]. Standard ten jest rozwijany przez

OPC Foundation7 i wskazany w referencyjnej architekturze systemów informatyki

przemysłowej RAMI 4.08.

W pracy [RC3] przedstawiłem zastosowanie serwera OPC UA jako bramy pomiędzy siecią

CAN i systemami cyberfizycznymi. Istotnymi ograniczeniami związanym z wykorzystaniem

sieci CAN w otwartych systemach komunikacyjnych są: fizyczne ograniczenia dotyczące

rozmiaru segmentu sieci CAN oraz brak informacji na temat znaczenia zmiennych

7 https://opcfoundation.org

8 Reference Architecture Model Industrie 4.0; https://www.plattform-i40.de


transmitowanych tą siecią. Standard OPC UA pozwala na pokonanie obu tych ograniczeń.

Standard OPC UA umożliwia komunikację bazującą na rodzinie protokołów TCP/IP oraz na

protokołach SOAP/HTTP. Oba te rozwiązania mogą być stosowane w systemach

cyberfizycznych. Do prezentacji metainformacji wspomagających interpretację

transmitowanych siecią CAN danych, wykorzystałem opisy gromadzone w bazie danych

środowiska wspomagającego uruchamianie systemów bazujących na sieci CAN. W trakcie

opisanego w publikacji eksperymentu korzystałem ze środowiska CANoe. Architekturę

zaproponowanego rozwiązania przedstawiłem na rys. 4.

Rys. 4. Architektura systemu łączącego sieć CAN z OPC UA

System wykorzystuje informacje dostępne w środowisku uruchomieniowym CANoe, które

importowane są z bazy DB++. Na tej podstawie Moduł A tworzy metainformacje na temat

poszczególnych obiektów, które są dostępne w przestrzeni adresowej serwera OPC UA jako

obiekty typu CANAddressType. Struktura informacji zawartych w obiektach CANAdressType

odpowiada sposobom adresacji wykorzystywanym w sieci CAN i pozwala na rozkodowanie

dabych transmitowanych tą siecią. Tworzone przez Moduł B obiekty typu CANoeAddressType

wykorzystują dodatkowe informacje dostępne w środowisku uruchomieniowym CANoe. Są

one prezentowane za pomocą serwera OPC UA. Klienci OPC UA mogą przeglądać zawartość

przestrzeni adresowej tego serwera i dokonywać subskrypcji istotnych dla nich informacji.


Moduł C jest odpowiedzialny za śledzenie datagramów przesyłanych magistralą CAN oraz za

wydobywanie na podstawie opisów zawartych w obiektach typu CANAddressType aktualnych

wartości transmitowanych zmiennych. Mechanizm subskrypcji zapewnia, że informacja

pomiędzy klientem i serwerem wymieniana jest jedynie w przypadku zmian wartości

parametrów transmitowanych siecią CAN, co powoduje minimalizację przepływu danych w

sieci zewnętrznej. Mechanizm VTQ (Value Time Quality) łączy wartość zmiennych z czasem

zarejestrowania nowej wartości po stronie magistrali CAN. Wyniki przeprowadzonych przeze

mnie testów efektywności zaproponowanego mechanizmu komunikacyjnego przedstawiłem w

pracy [37].

W pracy [RC4] zaprezentowałem model prezentacji metainformacji opisującej zależności

pomiędzy zmiennymi udostępnianymi w przestrzeni adresowej serwera OPC UA

dedykowanego dla autonomicznej platformy mobilnej. Rys. 5 przedstawia przestrzeń adresową

serwera OPC UA, która zbudowana jest z węzłów zawierających informacje i metainformacje

oraz z referencji łączących poszczególne węzły. Zarówno węzły, jak i referencje

reprezentowane są w oparciu o podejście obiektowe. Są one instancjami odpowiednich typów

definiowanych w przestrzeni adresowej OPC UA. Węzły ObjectType definiują przyjętą

strukturę danych. W przedstawionym przykładzie informacje te wiążą zarówno dane opisujące

położenie i jak ruch platformy mobilnej - Typ AMPType zawiera informacje na temat

położenia (Position) i ruchu platformy (Movement), parametry łącza wykorzystywanego do

komunikacji w systemie informatycznym (Address), jak również informacje związane z

aktualnie realizowanymi przez platformę zadaniami transportu materiałów (Task). Metody

zgrupowane w obiekcie Manual Control pozwalają na ręczne sterowanie ruchem platformy,

metody zgrupowane w obiekcie Automatic Services umożliwiają sterowanie automatyczne

poprzez przekazywanie parametrów trasy za pomocą skryptów języka Python lub plików CSV.

AMPType jest typem abstrakcyjnym, który definiuje przyjętą strukturę informacji.

Architektury platform mobilnych mogą różnić się między sobą, co wymaga uszczegółowienia

modelu informacyjnego AMP. Widoczna na rysunku definicja AMP_ADAS_Type prezentuje

szczegóły na temat czujników wykorzystywanych przez testowany rodzaj platformy mobilnej.

Przestrzeń adresowa serwera OPC UA reprezentuje także zależności pomiędzy

informacjami, które przedstawiane są za pomocą referencji. Referencje także mają postać

obiektów. Interpretacja powiązania za pomocą referencji jest określana przez jej typ, który

wskazuje na rodzaj zależności pomiędzy węzłami systemu. W prezentowanym przykładzie

występują referencje hierarchiczne wskazujące na strukturę obiektów złożnych

(HasComponent) oraz na zależność pomiędzy typem bazowym i pochodnym (HasSubType).

Rzeczywiste wartości zmiennych odzwierciedlających pracę platformy prezentowane są za

pomocą instancji odpowiednich typów. Zależność pomiędzy instancją typu a definicją

wyrażona jest za pomocą referencji HasTypeDefinition (ADAS1 i AMP_ADASType). W pracy

[RC5] przedstawiłem wykorzystanie dostępnego w OPC UA mechanizmu widoków, który


pozwala na stworzenie podzbioru informacji prezentowanej w przestrzeni adresowej OPC UA,

która dostępna jest za pomocą określonego widoku. Koncepcję tę zilustrowałem na przykładzie

bazującego na OPC UA modelu informacyjnego dedykowanego dla systemu komunikacji

publicznej.

Rys. 5. Model informacyjny autonomicznej platformy mobilnej opisany poprzez hierarchię

typów zdefiniowanych w przestrzeni adresowej OPC UA

4b.5 Omówienie wkładu habilitanta w zakresie warstwy komunikacji pośredniej

wykorzystywanej w systemach realizacji produkcji

Rozproszone systemy informatyczne oparte o realizowaną centralnie logikę systemu

sterowania i rozproszone moduły wejść/wyjść są obecnie zastępowane przez współpracujące

ze sobą komponenty tworzone w architekturze bazującej na usługach SOA (ang. Service

Oriented Architecture) [38]. Klasyczne rozwiązania sieci przemysłowych definiowane w

ramach standardu IEC 61158 (Industrial communication networks - Fieldbus specifications) i

standard określającego profile komunikacyjne IEC 61784 (Industrial communication networks

- Profiles) są ograniczeniem dla tworzenia systemów przemysłowych o architekturze SOA [39].

OPC UA jest pierwszym standardem komunikacji opartym na usługach, który został

powszechnie zaakceptowany przez przemysł. Standard ten definiuje usługi komunikacyjne w


sposób niezależny od ich implementacji. Dzięki temu może on być wykorzystywany do

łączenia ze sobą wielu typów systemów zlokalizowanych na różnych poziomach piramidy

automatyzacji i zrealizowanych przy pomocy odmiennych narzędzi informatycznych. W chwili

obecnej dostępne są implementacje OPC UA bazujące na rodzinie protokołów TCP / IP oraz

protokołach SOAP / HTTP. Obie implementacje zapewniają bezpieczeństwo wymiany

informacji poprzez zastosowanie infrastruktury klucza publicznego (PKI) z możliwością

szyfrowania transmisji oraz umożliwiają długotrwałe logiczne połączenia pomiędzy klientami

i serwerami OPC UA, które są realizowane za pomocą bezpiecznych kanałów

komunikacyjnych. Realizacja systemów komunikacyjnych bazujących na standzie OPC UA

jest obecnie możliwa dla środowisk programistycznych: C, Java i C#. Jedną z istotnych zalet

OPC UA jest jego skalowalność [40]. Wybór odpowiedniego profilu komunikacyjnego

pozwala na dopasowanie funkcjonalności serwera OPC UA tak do potrzeb związanych z daną

aplikacją, jak i do ograniczeń wynikających ze stosowanej bazy sprzętowej.

W pracy [RC6] zaproponowałem sposób realizacji oprogramowania serwera OPC UA

wbudowanego w układ FPGA. Dostarczane przez serwer usługi są zgodne ze specyfikacją

definiowanego przez OPC Foundation profilu „Nano Embedded Device Server”. Wybrany

zestaw usług OPC został zaimplementowany z wykorzystaniem stosu OPC UA udostępnionego

przez OPC Foundation w postaci kodu w języku C. Stos ten po niezbędnych adaptacjach został

zaimplementowany w procesorze MicroBlaze wbudowanym w układ FPGA. Przeprowadzone

testy serwera OPC UA w zakresie komunikacji sieciowej i uzyskane parametry kanału

komunikacyjnego potwierdziły możliwość wykorzystania przedstawionego rozwiązania

w systemach komunikacji typu soft real-time, w których wbudowany w układ FPGA serwer

OPC udostępniał kilkadziesiąt zmiennych procesowych przy opóźnieniu wnoszonym przez

kanał komunikacyjny na poziomie od 20 do 50 ms. Rozwinięciem opisanej koncepcji jest

specjalizowane rozwiązanie procesora komunikacyjnego dedykowanego dla sterowników PLC

i wbudowanego w układ FPGA. Zaproponowane rozwiązanie zostało zastrzeżone jako [Patent].

Akwizycja informacji z rozproszonych systemów sterowania do systemów MES może być

realizowana z wykorzystaniem istniejących sieci przemysłowych, jednak wprowadzenie

nowych abonentów sieci może zmienić zależności czasowe w systemach sterowania. W pracy

[RC7] przedstawiłem realizację i weryfikację eksperymentalną serwera OPC, który nie

wymaga wprowadzania dodatkowego abonenta sieci przemysłowej. Istotą pomysłu jest nasłuch

informacji wymienianych za pomocą sieci przemysłowej PROFINet I/O oraz wyodrębnianie

tych danych, które są subskrybowane przez klientów OPC. Na rys. 6 przedstawiłem przepływ

informacji w zaproponowanym systemie i podstawowe bloki oprogramowania pasywnego

serwera OPC.


Rys. 6. Przepływ informacji w pasywnym serwerze OPC udostępniającym informacje

transmitowane siecią przemysłową PROFINet I/O

Biblioteka WinPcap została wykorzystywana jest do przechwytywania ramek przesyłanych

siecią PROFINet. W trakcie eksperymentu korzystałem z przełącznika sieciowego rodziny

SCALANCE/Siemens, który umożliwiał kopiowanie ramek przechodzących przez port, do

którego podłączony był sterownik PLC i przekazywanie ich do portu wykorzystywanego przez

serwer OPC. Ze względu na specyfikę sieci PROFINet I/O konieczny był nasłuch dwóch typów

wymienianych informacji. Komunikacja bazująca na protokole TCP/IP prowadzona jest w

trybie „non-realtime”. Za jej pomocą przesyłane są informacje opisujące konfigurację logiczną

połączeń w sieci, które są niezbędne do prawidłowej identyfikacji kanałów komunikacyjnych.

Informacje transmitowane za pomocą protokołu PROFINET RT w trybie „realtime” były

wymieniane cyklicznie z okresem transmisji 1 ms. Informacje te zawierały aktualne stany

modułów wejść oraz wartości modułów wyjść zadawane przez sterownik PLC. Ze względu na

cykliczną wymianę informacji serwer OPC przekazywał do klientów jedynie nowe wartości

zmiennych przechwytywanych z sieci PROFINet I/O. Dzięki temu zmierzone natężenie ruchu

generowane przez protokół OPC było wielokrotnie niższe od ruchu generowanego przez

protokół PROFINET RT.

Niezawodne mechanizmy komunikacyjne są bardzo istotne nie tylko w systemach

sterowania, ale także wskazywane są jako jeden z kluczowych aspektów integracji i uzyskania


interoperacyjności w systemach realizacji produkcji [41]. W wielu przypadkach zbierane przez

systemy MES informacje mają kluczowe znaczenie dla potwierdzenia prawidłowej realizacji

technologii produkcyjnych czy wymaganej jakości produktów. Z tego powodu nawet

krótkotrwałe zakłócenia w komunikacji pomiędzy linią produkcyjną a systemem nadrzędnym

mogą skutkować zatrzymaniem linii produkcyjnej i wynikającymi z tego stratami. Klasyczne

technologie komunikacyjne nie są w stanie zapewnić niezawodnej i skutecznej komunikacji

pionowej [35]. W pracy [RC8] przedstawiłem wyniki badań związanych z wykorzystaniem

redundantnych kanałów komunikacyjnych celem zwiększenia niezawodności komunikacji

bazującej na standardzie OPC UA. Obok typowego dla schematu komunikacji klient - serwer

mechanizmu odczytu i zapisu zmiennych realizowanego w OPC UA przez usługi Read/Write

zawarte w grupie Atribute Service Set, OPC UA pozwala na bazującą na mechanizmie

subskrypcji komunikację za pomocą usług zdefiniowanych w grupie MonitoredItem Service

Set. Mechanizm subskrypcji umożliwia tworzenie logicznych kanałów wymiany informacji

w postaci sesji, które dzięki możliwości wprowadzania redundancji pozwalają na zwiększenie

niezawodności systemu komunikacyjnego.

Rozwiązania komunikacyjne bazujące na redundancji stosowane są w sieciach

przemysłowych, natomiast brak było takich badań dla systemów bazujących na protokole OPC

UA. Dla ich przeprowadzenia konieczne było stworzenie oprogramowania pośredniczącego

(ang. proxy) umieszczonego po stronie klienta OPC UA, które odpowiada za utrzymanie

i automatyczny wybór kanałów komunikacyjnych tworzonych z redundantnymi serwerami

OPC UA. Przełączenie kanałów jest niewidoczne dla klienta OPC UA i zapewnia ciągłość

kanału logicznego odpowiedzialnego za przepływ informacji. Analizowałem trzy możliwe do

zrealizowania w OPC UA tryby redundancji [42]: (i) tryb gorącej rezerwy, w którym moduł

proxy utrzymuje aktywne sesje zarówno w kanale podstawowym, jak i rezerwowym, (ii) tryb

ciepłej rezerwy, w którym sesje zapasowe są nawiązane, lecz nie są aktywne i nie następuje w

nich wymiana danych, ale jedynie kontrolowana jest poprawność łącza komunikacyjnego, (iii)

tryb zimnej rezerwy, w którym nawiązanie połączenia zapasowego następuje dopiero po utracie

połączenia w kanale podstawowym. Część eksperymentalna umożliwiła ocenę zakresu

stosowalności każdego z trybów redundancji poprzez weryfikację czasów przełączenia,

zajętości łącza komunikacyjnego i obciążenia procesora stacji pełniącej funkcję serwera OPC

UA w funkcji liczby zmiennych subskrybowanych przez pojedynczego klienta OPC oraz liczby

klientów subskrybujących ten sam zestaw zmiennych. Analiza wyników pozwoliła na

porównanie właściwości protokołu OPC UA w przypadku stosowania trzech analizowanych

trybów redundancji.


4b.6 Omówienie wkładu habilitanta w zakresie metod tworzenia profili

energetycznych stanowisk produkcyjnych na podstawie danych śledzonych w systemach

sterowania

Systemy sterowania mają dostęp do ogromnej ilości szczegółowych informacji niezbędnych

do prawidłowej realizacji procesu technologicznego. Zastosowanie metod eksploracji danych

pozwala na przekształcanie surowych danych produkcyjnych w informacje, które pozwolą na

bardziej skuteczną i efektywną realizację produkcji. Wśród obszarów zastosowania metod

eksploracji danych w systemach informatyki przemysłowej wymieniane są [43]: kontrola

jakości, planowanie zadań produkcyjnych na poziomie operacyjnym, diagnostyka błędów,

analiza procesów i systemów produkcji, utrzymanie zdolności produkcyjnych, analiza błędów

i poprawa wydajności produkcji. Wśród stosowanych narzędzi informatycznych wymieniane

są metody klasteryzacji, predykcji i analizy asocjacji. Jednym z kluczowych elementów

związanych z zastosowaniem mechanizmów eksploracji danych w przemyśle są systemy MES,

które przetwarzają informacje pobierane z systemów sterowania oraz umożliwiają analizę

danych i wydobywanie wiedzy technologicznej na podstawie analizy informacji i opisujących

je modeli [44]. W pracy [RC9] zaproponowałem algorytm pozwalający na analizę wpływu

poszczególnych faz procesu technologicznego na efektywność energetyczną stacji

produkcyjnej. Metoda ta pozwala na identyfikację istotnych ze względu na efektywność

energetyczną kroków cyklu produkcyjnego, które określane są w sposób automatyczny przez

analizę sygnałów sterujących PLC w zestawieniu ze zmianami zużycia mediów. Opracowaną

metodę zweryfikowałem w badaniach prowadzonych wspólnie z firmą AIUT Sp. z o. o., które

prowadziłem w ramach projektu EMC2(FP7-2011-NMP-ICT-FoF, Project ID: 285363).

Tematykę systemów informatycznych umożliwiających kontrolę efektywności

energetycznej stacji produkcyjnych kontynuowałem także w ramach realizacji zadania WP2

„Energy Efficient Production Systems for Automotive Industry” objętego projektem

AutoUniMo (FP7-PEOPLE-2013-IAPP, grant no.: 612207). W pracy [RC10] przedstawiłem

metodę i wyniki badań laboratoryjnych systemu informatycznego pozwalającego na

wyznaczanie profili energetycznych dla wielowariantowej produkcji dyskretnej. Główne

elementy rozwiązania zaprezentowano na rys. 7. Przedstawiony z lewej strony rysunku system

sterowania ma klasyczną architekturę stosowaną w produkcji dyskretnej. Oparty o sterownik

PLC system identyfikuje przetwarzany przez stację produkt i dobiera odpowiedni wariant

algorytmu sterowania. Sam proces sterowania realizowany jest poprzez cykliczne wykonanie

algorytmu zaimplementowanego w PLC. Interfejs operatora wykorzystywany jest do

komunikacji z obsługą w celu wskazania czynności, które mają być wykonane lub

nieprawidłowości, jakie wystąpiły w czasie produkcji. Zagregowane informacje o przebiegu

produkcji przekazywane są do systemu sterowania nadrzędnego, który może wpływać na wybór

i parametryzację algorytmów sterowania.


Rys. 7. Bloki funkcjonalne i przepływ informacji w systemie oceny efektywności

energetycznej dedykowanym dla wielowariantowej produkcji dyskretnej

Zaprezentowany po prawej stronie moduł analizy efektywności energetycznej składa się

z bloku śledzenia procesu produkcyjnego, umieszczonego w PLC oraz części analitycznej

wykorzystywanej do analizy śledzonych danych produkcyjnych. Umożliwia on automatyczną

adaptację systemu do nowych wariantów produkcji. System nie wymaga szczegółowych

informacji na temat realizowanego algorytmu sterowania a jedynie wykorzystuje obserwacje

sygnałów sterujących generowanych przez PLC. Analizowane są te sygnały, które sterują

urządzeniami będącymi istotnymi konsumentami energii. Określenie listy tych urządzeń

z rozbiciem na poszczególne media energetyczne jest dokonywane na podstawie projektu stacji

i listy wejść/wyjść sterownika PLC. Istotną informacją technologiczną jest sygnał informujący

o rozpoczęciu/ zakończeniu cyklu produkcyjnego, które w typowym przypadku wiązane są

z rozpoczęciem produkcji po identyfikacji profilu produkcyjnego i informacją o zakończeniu


produkcji. Dla każdego ze śledzonych obwodów wykonawczych rejestrowany jest czas pracy

urządzeń w cyklu produkcyjnym identyfikowanym przez sygnał START_CYCLE.

Jednocześnie rejestrowane jest zużycie każdego z mediów.

Informacje zebrane w śledzonych cyklach produkcyjnych stanowią wektor danych

wejściowych, które przetwarzane są w procesie uczenia maszynowego celem uzyskania

informacji o profilach energetycznych odpowiadających różnym wariantom realizowanej

technologii produkcyjnej. Zbiór uczący tworzony jest podczas śledzenia standardowego

procesu produkcyjnego realizowanego w produkcji wielowariantowej. Na tej podstawie

powstaje zbiór referencyjnych profili energetycznych, które wykorzystywane są do kontroli

efektywności energetycznej produkcji. W trybie kontroli dane zebrane w czasie śledzenia

nieznanego wariantu produkcji porównywane są z danymi referencyjnymi. W przypadku

niemożliwości wskazania odpowiadającego profilu system ostrzega o wystąpieniu anomalii,

która może być spowodowana poprzez nieprawidłowe działania obsługi, zmianę właściwości

materiałów lub awarię stacji produkcyjnej.

Jednym z napotkanych problemów jest konieczność klasyfikacji technologicznych

wariantów produkcji. W wielu przypadkach liczba tych wariantów różni się od liczby

wariantów wynikających ze specyfikacji produktu. Ta sama operacja produkcyjna może być

realizowana w różnych wariantach technologii. Różne typy produktów mogą być na danym

stanowisku produkowane w taki sam sposób. Problematykę automatycznej detekcji liczby

wariantów produkcji na podstawie obserwacji przebiegu dyskretnej przedstawiłem w pracy

[RC11]. Macierz danych X zawiera pomiary zebrane w trakcie realizacji (m) cykli

produkcyjnych. Cykle te zostały zrealizowane zgodnie z nieznaną liczbą (k) wariantów

technologicznych. W skład wektora opisującego każdy cykl produkcyjny wchodzi zmierzony

parametr określający kluczowy wskaźnik efektywności KPI (Key Performance Indicator),

który jest znormalizowany za pomocą współczynnika b oraz suma czasów pracy (T) dla

poszczególnych przypadająca na dany cykl produkcyjny.

𝐗 =

b ∗ KPI𝟏 T11 T1j T1n

b ∗ KPI𝐤 Tk1 Tkj Tkn

b ∗ KPI𝐦 Tm1 Tmj Tmn

Proponowana metoda polega na poszukiwaniu nieznanej liczby wariantów produkcji k

poprzez znalezienie takiego podziału zarejestrowanych wektorów danych z cykli

produkcyjnych, w którym dane pomiarowe zlokalizowane są wokół jednego jądra

reprezentującego wartości średnie składowych wektora cech. Ideę tę przedstawiłem na rys. 8.


Rys. 8. Wizualizacji danych pomiarowych dla klastra zawierającego jedno lub dwa jądra

Prawa strona rysunku przedstawia przypadek, w którym klaster zawiera dane zgromadzone

w trakcie realizacji pojedynczego wariantu technologicznego. Dane rozmieszczone są zgodnie

z rozkładem Gausa w n wymiarowej hiperkuli, której promień R określony jest przez

maksymalnie oddalony od centroidu klastra C wektor pomiarowy, a promień r przez średnią

odległość wektorów od centroidu w klastrze. W przypadku gdy wybrany podział danych

zawierałby dwa lub więcej wariantów, dane te byłyby rozłożone jak przedstawiono po lewej

stronie rys. 8. Ze względu na fakt, że algorytm K-Means zapewnia minimalizację błędu średnio

kwadratowego w każdym z klastrów [45], zaproponowany algorytm opiera się na wyznaczaniu

liczby wariantów k za pomocą analizy maksymalnego błędu w danym klastrze Ci, który

oznaczony jest jako Ri i wyliczony według formuły:

𝑅𝑖 = max1≤𝑗≤|𝑪𝑖|

(dist(𝒄𝑖 , 𝒙𝑗))

Średnia odległości wektorów Xj zawierających dane pomiarowe od centroidu i tego klastra

Ci oznaczona jako ri wyliczana jest według formuły:

ri =1

|𝐂i|∗ ∑ dist(𝒄𝑖 , 𝒙𝑗)

|𝐂i|

j=1

Funkcji jakości podziału Q(k) w zależności od wybranej liczby klastrów liczona jest zgodnie

z wzorem:

𝑄(𝑘) =1

k∗ ∑ (

𝑟𝑖

𝑅𝑖∗

𝑟𝑖

|𝑪𝑖|)

𝑘

𝑖=1

Poszukiwana liczba klastrów odpowiada wartości k dla której funkcja Q(k) przyjmuje

wartość k dla której funkcja Q(k) ma swoje minimum:

K = argmink

(Q(k))

Przedstawiona metoda została zweryfikowana zarówno dla danych symulacyjnych, które

zostały wygenerowane na bazie technologii typowej dla stanowisk wykorzystywanych


w produkcji dyskretnej, jak i na danych pochodzących z rzeczywistych stanowisk realizujących

wielowariantową produkcję dyskretną [46].

LITERATURA

[1] Harrington, J. (1979). Computer integrated manufacturing. RE Krieger Publishing Company

[2] Schmidt, K., & Bannon, L. (1992). Taking CSCW seriously. Computer Supported Cooperative Work

(CSCW), 1(1-2), 7-40

[3] Cheng, F. T., Shen, E., Deng, J. Y., & Nguyen, K. (1999). Development of a system framework for

the computer-integrated manufacturing execution system: a distributed object-oriented approach.

International Journal of Computer Integrated Manufacturing, 12(5), 384-402.

[4] McClellan, M. (1997). Applying manufacturing execution systems. CRC Press

[5] Huang, C. Y. (2002). Distributed manufacturing execution systems: A workflow perspective. Journal

of Intelligent manufacturing, 13(6), 485-497

[6] Choi, B. K., & Kim, B. H. (2002). MES (manufacturing execution system) architecture for FMS

compatible to ERP (enterprise planning system). International Journal of Computer Integrated

Manufacturing, 15(3), 274-284.

[7] Monostori, L. (2014). Cyber-physical production systems: roots, expectations and R&D challenges.

Procedia Cirp, 17, 9-13.

[8] Jones, C. T.. Programmable logic controllers: the complete guide to the technology. 1-6 A Tour of

PLC Evolution; pp17-23; Patrick-Turner Publishing Company Atlanta Philadelphia 1996

[9] Franck, D. T. (1973). Programmable Controllers-Today and Tomorrow. IEEE Transactions on

Industrial Electronics and Control Instrumentation, (4), 195-196

[10] Peshek, C. J., & Mellish, M. T. (1993, May). Recent developments and future trends in PLC

programming languages and programming tools for real-time control. In Cement Industry Technical

Conference, 1993. Record of Conference Papers., 35th IEEE (pp. 219-230). IEEE

[11] Stout, T. M.; Williams, T. J. (1995). "Pioneering Work in the Field of Computer Process Control".

IEEE Annals of the History of Computing. 17 (1): 6–18.

[12] Samad, T., McLaughlin, P., & Lu, J. (2007). System architecture for process automation: Review

and trends. Journal of Process Control, 17(3), 191-201

[13] Jacobs, F. R. (2007). Enterprise resource planning (ERP)—A brief history. Journal of Operations

Management, 25(2), 357-363.

[14] Al-Mashari, M., Al-Mudimigh, A., & Zairi, M. (2003). Enterprise resource planning: A taxonomy

of critical factors. European journal of operational research, 146(2), 352-364.

[15] Sauter, T. (2007). The continuing evolution of integration in manufacturing automation. IEEE

Industrial Electronics Magazine, 1(1), 10-19

[16] Chemane, L. A., Nunes, A. F., & Hancke, G. P. (1997, July). Industrial information infrastructure

and intelligent instrumentation-the options. In Industrial Electronics, 1997. ISIE'97., Proceedings of the

IEEE International Symposium on (Vol. 1, pp. 44-48). IEEE.

[17] Sauter, T.;Integration aspects in automation - a technology survey; Emerging Technologies and

Factory Automation, 2005. ETFA 2005. Volume: 9 pp.255 – 263, Sept. 2005

[18] Tao, F., Cheng, Y., Zhang, L., & Nee, A. Y. (2017). Advanced manufacturing systems: socialization

characteristics and trends. Journal of Intelligent Manufacturing, 28(5), 1079-1094.

[19] Arvidsson, V., Holmström, J., & Lyytinen, K. (2014). Information systems use as strategy practice:

A multi-dimensional view of strategic information system implementation and use. The Journal of

Strategic Information Systems, 23(1), 45-61


[20] Simão, J. M., Stadzisz, P. C., & Morel, G. (2006). Manufacturing execution systems for customized

production. Journal of Materials Processing Technology, 179(1), 268-275.

[21] Lemaignan, S., Siadat, A., Dantan, J. Y., & Semenenko, A. (2006, June). MASON: A proposal for

an ontology of manufacturing domain. In Distributed Intelligent Systems: Collective Intelligence and

Its Applications, 2006. DIS 2006. IEEE Workshop on (pp. 195-200). IEEE.

[22] Jardim-Goncalves, R., Grilo, A., & Steiger-Garcao, A. (2006). Challenging the interoperability

between computers in industry with MDA and SOA. Computers in Industry, 57(8-9), 679-689.

[23] Helo, P., Suorsa, M., Hao, Y., & Anussornnitisarn, P. (2014). Toward a cloud-based manufacturing

execution system for distributed manufacturing. Computers in Industry, 65(4), 646-656.

[24] Zhong, R. Y., Dai, Q. Y., Qu, T., Hu, G. J., & Huang, G. Q. (2013). RFID-enabled real-time

manufacturing execution system for mass-customization production. Robotics and Computer-Integrated

Manufacturing, 29(2), 283-292.

[25] Zhong, R. Y., Huang, G. Q., Lan, S., Dai, Q. Y., Chen, X., & Zhang, T. (2015). A big data approach

for logistics trajectory discovery from RFID-enabled production data. International Journal of

Production Economics, 165, 260-272.

[26] Zhang, Y., Zhang, G., Wang, J., Sun, S., Si, S., & Yang, T. (2015). Real-time information capturing

and integration framework of the internet of manufacturing things. International Journal of Computer

Integrated Manufacturing, 28(8), 811-822.

[27] Xu, X. (2012). From cloud computing to cloud manufacturing. Robotics and computer-integrated

manufacturing, 28(1), 75-86.

[28] Lee, J., Kao, H. A., & Yang, S. (2014). Service innovation and smart analytics for industry 4.0 and

big data environment. Procedia Cirp, 16, 3-8.

[29] Kang, H. S., Lee, J. Y., Choi, S., Kim, H., Park, J. H., Son, J. Y., ... & Do Noh, S. (2016). Smart

manufacturing: Past research, present findings, and future directions. International Journal of Precision

Engineering and Manufacturing-Green Technology, 3(1), 111-128.

[30] Rajkumar, R. R., Lee, I., Sha, L., & Stankovic, J. (2010, June). Cyber-physical systems: the next

computing revolution. In Proceedings of the 47th Design Automation Conference (pp. 731-736). ACM.

[31] Drath, R., & Horch, A. (2014). Industrie 4.0: Hit or hype? IEEE industrial electronics magazine,

8(2), 56-58.

[32] T.J. Williams, P. Bernus, J. Brosvic, D. Chen, G. Doumeingts, L. Nemes, J.L. Nevins, B. Vallespir,

J. Vlietstra, D. Zoetekouw, Architectures for integrating manufacturing activities and enterprises,

Computers in Industry. 24 (1994) 111–139

[33] The International Society of Automation, ANSI/ISA-95.00.04-2012 Enterprise-Control System

Integration − Part 4: Objects and attributes for manufacturing operations management integration,

(2012)

[34] J.H. Christensen, Holonic manufacturing systems: initial architecture and standards directions, Proc

1st Euro Wkshp Holonic Manuf. Syst. (1994)

[35] Wollschlaeger, M., Sauter, T., & Jasperneite, J. (2017). The future of industrial communication:

Automation networks in the era of the internet of things and industry 4.0. IEEE Industrial Electronics

Magazine, 11(1), 17-27.

[36] Müller, M., Wings, E., & Bergmann, L. (2017, July). Developing open source cyber-physical

systems for service-oriented architectures using OPC UA. In Industrial Informatics (INDIN), 2017 IEEE

15th International Conference on (pp. 83-88). IEEE.

[37] Cupek, R., Ziębiński, A., Drewniak, M., & Fojcik, M., 2017, Feasibility Study of the Application

of OPC UA Protocol for the Vehicle-to-Vehicle Communication, In Conference on Computational

Collective Intelligence Technologies and Applications, part of the Lecture Notes in Computer Science

book series LNCS, Springer, Cham, pp. 282-291.

[38] F. Jammes, H. Smit,” Service-Oriented Paradigms in Industrial Automation,” IEEE T. Ind. Inform.,

vol. 1, no. 1, pp. 62–70, Feb. 2005.


[39] M. Felser, ”Real-Time Ethernet - Industry Prospective,” P. IEEE, vol. 93, no. 6, pp. 1118–1129,

June 2005.

[40] IMTIAZ, Jahanzaib; JASPERNEITE, Jürgen. Scalability of OPC-UA down to the chip level

enables “Internet of Things”. In: Industrial Informatics (INDIN), 2013 11th IEEE International

Conference on. IEEE, 2013. p. 500-505.

[41] Panetto, H., & Molina, A. (2008). Enterprise integration and interoperability in manufacturing

systems: Trends and issues. Computers in industry, 59(7), 641-646.

[42] J. Lange, F. Iwanitz, T. J. Burke, OPC - From Data Access to Unified Architecture, VDE Verlag,

2010, pp. 196-201

[43] Choudhary, A. K., Harding, J. A., & Tiwari, M. K. (2009). Data mining in manufacturing: a review

based on the kind of knowledge. Journal of Intelligent Manufacturing, 20(5), 501.

[44] Zhang, Y., Ren, S., Liu, Y., & Si, S. (2017). A big data analytics architecture for cleaner

manufacturing and maintenance processes of complex products. Journal of Cleaner Production, 142,

626-641.

[45] Steinley, D., Brusco, M.J.: Initializing K-means Batch Clustering: A Critical Evalua-tion of

Several Techniques. Journal of Classification. 24, 99–121 (2007)

[46] 1. Cupek R., Ziebinski A., Drewniak M., Fojcik M., 2018, Estimation of the Number of Energy

Consumption Profiles in the Case of Discreet Multi-Variant Production, In Intelligent Information and

Database Systems part of Lecture Notes in Artificial Intelligence book series LNAI, Springer, volume

10752, pp. 674-684.


5. Omówienie pozostałych osiągnięć naukowo - badawczych

a) Publikacje

Wynikiem mojej pracy naukowej po uzyskaniu tytułu doktora nauk technicznych są łącznie

63 publikacje, z czego 7 publikacji zostało wydanych w czasopismach ujętych w bazie Journal

Citation Reports. Sumaryczny impact factor moich publikacji wynosi 7,16. Sumaryczna liczba

punktów MNSW to 531. W bazie Web of Science widocznych jest 26 publikacji, których byłem

współautorem. Liczba cytowań tych prac to 68, liczba cytowań z pominięciem autocytowań to

36. Mój Indeks Hirscha wg WoS wynosi 5(3). W bazie Scopus widocznych jest 38 publikacji,

liczba cytowań to 118, liczba cytowań z pominięciem autoocytowań to 53. Indeks Hirscha wg

Scopus wynosi 7(4). Poniżej przedstawiam wydruki indeksów z obu baz według stanu na dzień

29.03.2018


b) Udział w projektach badawczych

Od października 2017 r. jestem jednym z kluczowych wykonawców realizowanego przez

firmę AIUT Sp. z o. o. projektu NCBiR POIR.01.02.00-00-0307/16-00 – INNOMOTO pt.:

„Knowledge integrating shop floor management system supporting preventive and

predictive maintenance services for automotive polymorphic production framework”.

W okresie 2013-2017 pełniłem w Politechnice Śląskiej funkcję koordynatora projektu FP7-

PEOPLE-2013-IAPP (Industry Academia Partnerships and Pathways) pt.” AutoUniMo

Automotive Production Engineering Unified Perspective based on Data Mining Methods

and Virtual Factory Model” - http://autounimo.aei.polsl.pl. Byłem także wykonawcą tego

projektu i uczestniczyłem w 24 miesięcznym oddelegowaniu do firmy Continental

Ingolstadt celem realizacji zadań w ramach pakietu “WP1 Manufacturing Execution System

for Short Series Production Support”

W okresie 2014 – 2016 pełniłem w Politechnice Śląskiej funkcję koordynatora projektu

Polish-Norwegian Research Programme, Norwegian Financial Mechanism 2009-2014

grant no. Pol-Nor/204256/16/2013 pt.: „MEDUSA - Automated Assessment of Joint

Synovitis Activity from Medical Ultrasound and Power Doppler Examinations Using

Image Processing and Machine Learning Methods” - http://medusa.aei.polsl.pl.

W okresie 2012-2014 pełniłem funkcję kierownika i wykonawcy realizowanego przez

firmę AIUT Sp. z o. o. projektu FP7-2011-NMP-ICT-FoF – (Information and

Communication Technologies/ Factories of the Future) pt.: „EMC2 The Eco-Factory:

cleaner and more resource-efficient production in manufacturing”,

https://cordis.europa.eu/project/rcn/101388_en.html

W okresie 2009-2013 pełniłem funkcję zastępcy kierownika realizowanego w Politechnice

Śląskiej projektu EkDan (grant POKL.04.01.01-00-106/09) „Utworzenie nowej

specjalności studiów doktoranckich w dyscyplinie Informatyka na Wydziale Automatyki,

Elektroniki i Informatyki pt. Eksploracja Danych (Data Mining). W ramach projektu

współuczestniczyłem w uzgadnianiu i przygotowaniu wykładów zapraszanych, w których

brali udział krajowi i zagraniczni naukowcy oraz eksperci z przemysłu.

W okresie 2008-2009 pełniłem w Politechnice Śląskiej funkcję kierownika projektu

Norway Grants, seminar project grant no.: PNRF164-AII-1/07 „Geology and Information

Technology”.

c) Omówienie działalności dydaktycznej i organizacyjnej

Rezultaty przedstawionych w osiągnięciu prac badawczych wykorzystałem do

przygotowania wykładów, zajęć laboratoryjnych i tematów prac magisterskich. Poniżej

przedstawiam najważniejsze osiągnięcia związane z moim udziałem w studiach doktoranckich,

magisterskich i w działalności organizacyjnej Wydziału Automatyki, Elektroniki i Informatyki.

http://medusa.aei.polsl.pl/

http://autounimo.aei.polsl.pl/

https://cordis.europa.eu/project/rcn/101388_en.html


5.c.1 Studia doktoranckie

Aktualnie pełnię funkcję promotora pomocniczego w doktoracie realizowanym przez mgr

inż. Marka Drewniaka pt. „Metody analizy efektywności i jakości procesów produkcji

dyskretnej wykorzystujące wybrane mechanizmy eksploracji danych”.

Występuję w roli opiekuna w realizowanym przez mgr inż. Łukasza Huczałę doktoracie pt.

„Modele wymiany informacji w elastycznych aplikacjach klasy B2M (Business-To-

Manufacturing)”.

Od r. 2012 r. prowadzę wykład dla studentów studiów doktoranckich pt. „Konstrukcja

i oprogramowanie systemów komputerowych”.

W okresie 2014 - 2017 sprawowałem opiekę naukowa nad doktorantami oddelegowanymi

do przemysłu w ramach projektu AutoUniMo: dwóch doktorantów oddelegowanych do

Continenetal Ingolstadt oraz jeden doktorant oddelegowany do AIUT Sp. z o. o.

W okresie 2009 - 2013 pełniłem funkcję zastępcy kierownika projektu EkDan, którego

celem była organizacja studiów doktoranckich o specjalności eksploracja danych.

W ramach projektu EkDan sprawowałem opiekę naukową nad pięcioma doktorantami oraz

przygotowałem i prowadziłem wykład w języku angielskim pt. „Data Mining in industrial

computer systems”.

5.c.2 Studia magisterskie

Byłem promotorem ponad 50 prac magisterskich.

Od 2003 r. prowadzę przedmiot w języku angielskim (wykład + laboratorium) dla

studentów Makrokierunku pt. „Distributed Computer Systems”.

Od 2003 r. prowadzę przedmiot (wykład + laboratorium) na specjalności Informatyczne

systemy przemysłowe pt.: „Wizualizacja procesów przemysłowych”.

W okresie 2000 – 2005 opracowałem i prowadziłem wykład i laboratoria dla studentów na

kierunku Informatyka pt.: „Rozproszone systemy komputerowe”.

W okresie 2009 – 2014 prowadziłem na specjalności Przemysłowe systemy komputerowe

przedmiot pt. „Systemy operacyjne czasu rzeczywistego”, a w okresie 2012 – 2016

przygotowałem i prowadziłem wykład dla specjalności Informatyka w lotnictwie pt. „Sieci

komputerowe w lotnictwie”.

5.c.3 Wykłady zagraniczne

W okresie 2008-2009 prowadziłem przedmiot „Industrial Computer Systems” (wykład,

laboratorium, projekt) w Technische Hochschule Ingolstadt, Niemcy, Wydział

Elektrotechniki i Informatyki o łącznym wymiarze zajęć: 120 godzin.

Rafal Cupek - zat.2 autoreferat w iEzyku polskinr 38

5.c.4 DzialalnoSd organizacyj na

'. W okresie 2008-2012 pelnilem funkcjE Prodziekana ds. Studenckich na Wydziale

Automatyki Elektroniki i Informatyki Politechniki Sl4skiej.'/ W okresie 2012-2013 funkcjg Prodziekana ds. Organizacji i Rozwoju na Wydziale

Automatyki E,l ektroniki i Informatyki Po I itechn iki S l4skie.i.

/"//**'

Dr in2. Rafal Cupek

do wniosku z dnia 29 marca 2018 roku o przeprowadzenie ...€¦ · Doktor nauk technicznych w...

Documents

Transcript of do wniosku z dnia 29 marca 2018 roku o przeprowadzenie ...€¦ · Doktor nauk technicznych w...