SYSTEMY SMART CITIES STUDIUM ?· Systemy Smart Cities – studium przypadku 165 zyjnego opisu stosownych…

  • Published on
    28-Feb-2019

  • View
    212

  • Download
    0

Embed Size (px)

Transcript

Z E S Z Y T Y N A U K O W E P O L I T E C H N I K I P O Z N A S K I E J

Nr 63 Organizacja i Zarzdzanie 2014

Cezary OROWSKI*

SYSTEMY SMART CITIES STUDIUM PRZYPADKU

W artykule przedstawiono architektur szyny integracyjnej wykorzystywanej w budo-

wie systemu informatycznego przetwarzajcego potne zasoby danych na potrzeby po-dejmowania decyzji w Urzdzie Miejskim w Gdasku. Na wstpie omwiono kluczowe

z punktu widzenia wytwarzania szyny procesy: instalacji rodowiska wytwarzania, pod-

czenia bazy danych, opracowania mechanizmw przepywu oraz prezentacji danych. Pro-

cesy prezentacji wsparto modelami KPI (ang. key processes identifier) oraz SOP

(ang. simple operating procedures) (take podczonymi do szyny). W podsumowaniu

wskazano na problemy budowy szyn integracyjnych, a zwaszcza procesw: trasowania,

konwersji i obsugi zdarze.

Sowa kluczowe: systemy Smart Cities, systemy oparte na wiedzy, Service Oriented Architecture, Enterprise Service Bus, Software as

a Service

1. WPROWADZENIE

W zwizku z 70. rocznic urodzin Pana Profesora Leszka Pacholskiego, planu-jc referat do specjalnego numeru Zeszytw Naukowych Politechniki Pozna-

skiej, zastanawiaem si nad jego tematyk. Mogem powici go ergonomii

systemw informatycznych lub tematyce z pogranicza informatyki i zarzdzania,

ale po rozmowach z Profesorem zdecydowaem si powici ten artyku tematyce, ktra go intryguje systemom opartym na wiedzy (ang. knowledge based systems)

[1, 2], przetwarzajcym potne zasoby informatyczne (ang. big data) [6]. Pragn-

em take, aby zakres tej pracy obejmowa procesy zarzdzania, std artyku po-wicony jest projektowaniu systemw opartych na wiedzy dla systemw Smart

* Gdansk IBM Center for Advanced Studies on Campus.

Cezary Orowski 164

Cities. Przedstawiono w nim przykad systemu jako usugi (ang. Software as a Service), jak te architektury systemu integracji usug SOA (ang. Software Orien-

ted Architecture).

Budowa systemw informatycznych przetwarzajcych znaczne dane wymaga

architektury, ktra z jednej strony integruje te dane, ale przede wszystkim stwarza warunki do integracji aplikacji [3, 4, 5]. Do poowy poprzedniej dekady domino-

wao podejcie, w ramach ktrego integracja zasobw nastpowaa z wykorzysta-

niem hurtowni danych aplikacji przez (1) tworzenie warstw middleware, (2) zasto-sowanie rozwiza Enterprise Application Integration, (3) tworzenie protokow

API (ang. Applictaion Protocol Interface) bd (4) projektowanie indywidualnych

interfejsw GUI (ang. Graphical User Interface). W przypadku wielu problemw

zwizanych z integracyjnymi systemami informatycznymi przedsibiorstw wdro-enie tych rozwiza byo czasochonne, a one same nie stwarzay moliwoci

rozwoju.

Dlatego te coraz wiksza grupa aplikacji tworzona jest z wykorzystaniem ar-chitektury szyny integracyjnej ESB (ang. Enterprise Service Bus). ESB to zorien-

towana na usugi platforma czca aplikacje oparte na zrnicowanych technolo-

giach, niekompatybilnych formatach i zasobach danych oraz protokoach komuni-kacyjnych [7, 8]. Zalet tego rozwizania jest przede wszystkim dynamiczna kon-

wersja i transformacja danych (ang. dynamic data transformation and conversion),

rozproszona komunikacja (ang. distributed communication) oraz inteligentne tra-

sowanie usug (ang. inteligent service routing) [13]. Z tego te powodu przed przystpieniem do budowy systemu na potrzeby Urz-

du Miejskiego podjto decyzj o wyborze architektury systemu opartego na SOA

i wspartego ESB. Kolejno okrelono wymagania wobec systemu, zaprojektowano architektur danych z wykorzystaniem rodowiska MS oraz aplikacji opartej

na RAS (ang. Rational Software Architect). Szyn integracyjn zbudowano, wyko-

rzystujc Brocket Toolkit. System informatyczny zobrazowano z zastosowaniem IOC (ang. Intelligent Oprating Center). Podsumowaniem artykuu s wnioski

i spostrzeenia autora skoncentrowane zarwno na problemach budowy modelu

szyny i jej implementacji, jak i na implementacji systemu IOC.

2. WYMAGANIA WOBEC SYSTEMU IOC

Proponowany system IOC to inteligentny system zarzdzania miastem, ktry

(z racji swoich funkcji) wykorzystuje dane pobierane z wielu rde (z sieci moni-toringu rodowiska, z zasobw sieci przemysowych, z repozytorium zarzdzania

kryzysowego (kamer, systemw bezpieczestwa, systemw wczesnego ostrzegania

i innych)). W przypadku Gdaska analiza wymaga dotyczcych zanieczyszcze, koncepcji projektu oraz budowy systemu wspomagania decyzji wymagaa precy-

Systemy Smart Cities studium przypadku 165

zyjnego opisu stosownych baz danych. W procesie analizy wymaga brano pod uwag zarwno wymagania, jak i dostpne dane, stosujc dwa podejcia, odmienne

z punktu widzenia procesw budowy baz danych i ich zasilania. W pierwszym

podejciu zakadano bezporednie zasilanie systemu IOC danymi od partnerw

projektw. Drugie podejcie polegao na budowie hurtowni danych zasilanej z poziomu zewntrznych baz danych partnerw projektowych. Przed wyborem

rozwizania przeprowadzono testy obu podej.

Przypadek pierwszy wymaga z jednej strony analizy rnych standardw baz danych, ale z drugiej strony moliwoci zasilania budowanego systemu danymi

o zrnicowanym standardzie. Dlatego te przeprowadzono dwa eksperymenty.

W ramach pierwszego wyspecyfikowano wymagania dotyczce danych i ich stan-

dardu (Armaag dane dotyczce zanieczyszcze, Urzd Miejski dane dotyczce haasu, Politechnika Gdaska zanieczyszczenia i warunki atmosferyczne) i pr-

bowano rwnolegle zasila baz danych IOC [9, 10].

Stosunkowo szybko okazao si, e zasilanie rwnolege jest bardzo trudne do uzyskania i dlatego zdecydowano si na wstpne zasilanie danymi wsadowymi

(podejcie II), aby oceni przydatno danych, a nastpnie mechanizmy ich pozy-

skiwania. W przypadku przetwarzania wsadowego nie stwierdzono problemw z uzyskiwaniem danych, ale pojawia si problem powtarzalnoci takiego wsado-

wego zasilania. Opracowano take procesy zasilania zarwno hurtowni, jak i IOC.

Kolejnym wanym pytaniem byo usytuowanie systemu baz danych. Na wst-

pie sugerowano, aby system baz danych by ulokowany na tym samym serwerze, na ktrym postawiono IOC. Okazao si jednak, e zarwno z punktu widzenia

procesw testowania, jak i pniejszego wytwarzania, zdecydowanie lepszym

rozwizaniem (z punktu widzenia bezpieczestwa) jest usytuowanie systemu baz danych na serwerze zewntrznym w stosunku do IOC.

Ostatnim problemem bya kwestia standardu hurtowni baz danych. Brano pod

uwag dwa standardy, *. SQL oraz *. DB2. Z punktu widzenia IOC lepszym (spe-niajcym wymagania IOC) rozwizaniem by standard baz danych DB2. Brano jed-

nak pod uwag dowiadczenie czonkw zespou, ktrym standard DB2 nie by

znany. Dlatego te zdecydowano si na standard SQL, mimo e bardziej rozwojowy

wydawa si DB2. Decyzja o wyborze standardu bardziej znanego, a nie bardziej rozwojowego, wynikaa z koniecznoci ograniczenia ryzyka projektowego.

3. ARCHITEKTURA SZYNY INTEGRACYJNEJ

Architektur systemu przedstawiono na rys. 1. Skada si ona z trzech warstw,

tworzcych szyn integracyjn zapewniajc przepyw danych. Warstwa danych

(wze database input node) umoliwia podczenie do szyny integracyjnej bazy danych (w rozpatrywanym przypadku hurtownie danych akwilon2). Warstwa

Cezary Orowski 166

przetwarzania (wze mapping node) konwertuje dane z hurtowni danych do pro-tokou szyny integracyjnej CAP (ang. common alerting protocol). Z kolei wze

MQ qutput node (warstwa prezentacji) ma za zadanie umieci zdarzenia w for-

macie CAP w menederze kolejek szyny integracyjnej. rodowiskiem implemen-

tacji architektury systemu bya aplikacja firmy IBM WebSphere Message Broker Toolkit (konstrukcja szyny) oraz Netcool Impact (umieszczanie zdarze na mapie

systemu IOC) [12].

Rys. 1. Szyna integracyjna systemu zapewniajca przepyw danych na potrzeby systemu IOC

Zoony proces przepywu danych zosta zobrazowany na przykadzie wykorzy-

stania zasobw (warstwa danych). Na poziomie tej warstwy sprawdza si, czy

w tabeli IOC_appliaction w bazie danych akwilon2 znajduj si wiersze zawierajce

dane z 85 stacji pomiaru haasu. Jeeli tak, to uruchamiany jest wyzwalacz IOCAPPL (rys. 2) nowych rekordw (polecenie insert), ktry jednoczenie tworzy

rekordy z tym samym ID w tabeli IOC_Event. Tabele IOC_event i IOC_application

poczone s relacj poprzez klucz gwny ID [11]. Na rysunku 2 przedstawiono fragment kodu wyzwalacza umoliwiajcego operacje na wierszach obu tabel.

Websphere Message

Broker Toolkit

Appliplica-

ca-tion

Event

MS SQL Server

SQL CAP XML

MQ Explorer IOC

Mapa +

Lista pomiarw

Warstwa danych Przetwarzanie Warstwa prezentacji

Systemy Smart Cities studium przypadku 167

Rys. 2. Fragment kodu wyzwalacza umoliwiajcego operacje na wierszach obu tabel

Na rysunku 3 przedstawiono obie tabele bazy danych akwilon2.

Rys. 3. Tabele bazy danych systemu akwilon2 (ioc_event oraz IOC aplliaction)

4. WNIOSKI

W artykule przedstawiono architektur oraz implementacj szyny integracyjnej

ESB na potrzeby systemu IOC. W trakcie budowy szyny ESB napotkano dwie

grupy problemw: uruchomienia i utrzymania przepyww danych oraz wykorzy-stania rodowiska deweloperskiego do implementacji i modyfikacji architektury

szyny.

Cezary Orowski 168

W pierwszym przypadku uruchomienie i utrzymanie przepyww wi si gwnie z problemami z konwersj danych i ze stale pojawiajcym si pytaniem

czy szyn zasila niezalenie, czy te poprzez hurtownie danych. Kolejnym pro-

blemem okazao si zastosowanie procesw: move, assign i concept w procesach

mapowania danych. O ile proste procesy move umoliwiay konwersj danych do protokou CAP, o tyle proces assign, a w szczeglnoci concept, nie zawsze wspie-

ra proces konwersji. Podobne problemy pojawiay si w procesach kolejkowania

zdarze. Wielokrotne prby odwieania zdarze zapeniay baz i nie pozwalay na poprawne dziaanie wyzwalacza wierszy bazy danych. Dlatego te wielokrotnie

sigano po dokumentacj rodowiska deweloperskiego, aby usun pojawiajce si

problemy.

W drugim przypadku zastosowanie rodowiska deweloperskiego Websphere Message Broker Toolkit umoliwio konstruowanie szyny, ale nie wszystkich

warstw proponowanej architektury. O ile architektura high level szyny ESB bya

stosunkowo prosta, o tyle wczanie kolejnych aplikacji deweloperskich nie zawsze wspierao implementacj przepywu. Na przykad stosunkowo czsto wystpoway

problemy z budow modeli KPI lub SOP. Poniewa oba modele mona byo two-

rzy na dwa sposoby z wykorzystaniem Websphere Message Broker Toolkit lub Websphere Business Monitor Development Toolkit, nie zawsze wybr narzdzia

gwarantowa poprawno modelu. Podobnie jak w pierwszym przypadku, wielo-

krotnie sigano do dokumentacji. Cige zatrzymywanie projektu zmniejszao tem-

po jego realizacji. Naley jednak podkreli, e o ile proces budowy systemu IOC przetwarzajce-

go potne dane na potrzeby decydentw Urzdu Miejskiego w Gdasku okaza si

stosunkowo zoony, o tyle proces zmian systemu jest stosunkowo prosty. rodo-wisko deweloperskie jest trudne w instalacji, zapewnia jednak wielowtkow reali-

zacj procesu zmian. Dlatego te nakad pracy przeznaczony na proces instalacji

rodowiska szybko przekada si na wydajno tego rodowiska w procesach zmian budowanego systemu IOC. Dlatego te przedstawiony przykad budowy

szyny integracyjnej ESB na potrzeby Urzdu Miejskiego naley uzna za pozy-

tywny.

LITERATURA

[1] Bhowmick A., IBM Intelligent Operations Center for Smarter Cities Administration

Guide 5. Event flow diagnostic and validation tool for IBM WebSphere Business

Monitor, International Business Machines Corporation, 2009.

[2] Common Alerting Protocol Version 1.2 http://docs.osasis-open.org/emergency/cap/

v1.2/CAP-v1.2-os.pdf

http://docs.osasis-open.org/emergency/cap/%20v1.2/CAP-v1.2-os.pdfhttp://docs.osasis-open.org/emergency/cap/%20v1.2/CAP-v1.2-os.pdf

Systemy Smart Cities studium przypadku 169

[3] Czarnecki A., Orowski C., Sitek T., Zikowski A., Information technology assess-

ment using a functional prototype of the agent based system, Foundations of Control

and Management Sciences, 2009, s. 7-28.

[4] Czarnecki A., Orowski C., Ontology as a tool for the IT management standards sup-port Agent and Multi-Agent Systems: Technologies and Applications, 2009,

s. 330-339.

[5] IBM Intelligent operations center Information Center, http://publib.boulder.ibm.com/

infocenter/wasinfo/v6r0/index.jsp (dostp: 2013).

[6] IBM WebSpher application server information center, http://publip.boulder.ibm.com/

infocenter/cities/v1r5m0/index.jsp (dostp: 2013).

[7] IBM WebSphere Broker Message Broker Information Center, http://publib.boulder.

ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp (dostp: 2013).

[8] Kortas K., Data integration using ESB IBM Websphere Message Broker, Diploma

dissertation, Gdask 2013.

[9] Orowski C., Kowalczuk Z., Knowledge management based on dynamic and self- -adjusting fuzzy models, in Knowledge-Based Intelligent Information and Engineering

Systems, Springer, BerlinHeidelberg 2006.

[10] Orowski C., Zikowski A., Czarnecki A., Validation of an agent and ontology-based

information technology assessment system, Cybernetics and Systems: An International

Journal, 2011, Vol. 41 (1), s. 62-74.

[11] Pastuszak J., Stolarek M., Orowski C., Concept of generic IT organization evolution

Model, Faculty of ETI Annals, Information Technologies, 2008, Vol. 18, s. 235-240.

[12] Snadach K., Graphical data presentatation in IBM Intelligent Operations Center,

Diploma Dissertation, Gdask, 2013.

[13] Smith A.D., IBM Intelligent Operations Center KPI Implementers Guide for

Websphere Software, Document version 1.0.

SMART CITIES SYSTEMS A CASE STUDY

Summary

This paper presents the architecture of an enterprise service bus used in the construction

of information systems processing large amounts of data for decision-making needs at the

City Hall in Gdansk. The first part presents the key processes of bus development: installa-

tion of developing environment, database connection, flow mechanisms and data presenta-

tion. Developing processes were supported by models such as KPI (Key Processes Identi-fier) and SOP (Simple Operating Procedures) (also connected to the bus). The summary

indicates problems in bus construction, especially processes such as routing, conversion,

and handling of events.

http://publib.boulder.ibm.com/%20infocenter/wasinfo/v6r0/index.jsphttp://publib.boulder.ibm.com/%20infocenter/wasinfo/v6r0/index.jsphttp://publip.boulder.ibm.com/%20infocenter/cities/v1r5m0/index.jsphttp://publip.boulder.ibm.com/%20infocenter/cities/v1r5m0/index.jsp

Cezary Orowski 170

Recommended

View more >