Pojęcie techniki sterowania wind, jeszcze długo nie będzie oznaczać lokalnych systemów, które są autonomiczne, będą częściowo niezależne i składaj  się z kombinacji maszyny z maszyn, choćby w przypadku zadania wewnętrznego, zajmuje coraz więcej miejsca.

Na przykładzie rozwiązania zastosowanego w szpitalu, tekst ten powinien wyjaśnić, jak system „winda” zintegrowany został z nadrzędnym systemem „szpital” z zachowaniem reguł dotyczących specyficznego przeznaczenia budynku. Co istotne, rzecz odbyła się przy wdrożeniu najnowszych komponentów automatyzacji. W Amsterdam Medical Center, zadanie obejmowało integrację systemu dostępu z kartą transpondera (zespołu odbiornika i nadajnika satelity telekomunikacyjnego) dla zespołu reanimacyjnego, personelu opieki, służby wartowniczej i techników. Przy czym sygnał musi docierać do wszystkich zasobów wind w budynku. Do tego trzeba było uporać się z zadaniami sterowni, które wchodzą w skład klasycznego zestawu windy i wymagają osieciowania przestrzennego w budowli.

Rysunek 1: model komunikacji między producentem a konsumentem (np. PDO i NMT) Producent > konsument	Rysunek 2: model komunikacji klienta z serwerem (np. SDO) Klient−prośba−>serwer−odpowiedź...

Obserwując przepływ informacji w obrębie urządzenia windy, widać, że obok klasycznego sygnału uruchomienia, zastosowane zostały systemy magistrali danych, które charakteryzują: możliwe do przewidzenia zachowanie w czasie i jasne reguły dostępu. Konstruktywnie zrealizowane zostały naniesione zmiany oraz w zależności od przeznaczenia różne modele komunikacji (jak ten przedstawiony według schematu na rysunku 1, model producenta−konsumenta lub na rysunku 2, uproszczony model server−klient). Wyznaczony został też priorytetowy cel. Typowym przykładem na to jest kombinacja magistrali danych CAN z CANopen, ze zrealizowanym obiektem danych procesu (PDO), przedmiotem danych serwi− su (SDO) i funkcjami zarządzania siecią (NMT).

Schemat komunikacji

Żeby zagwarantować interakcję komponentów różnych producentów, użyto w tym przypadku profilu zastoso− wania (CiA 417). Określał on, jakie informacje znajdują się, w których danych obiektu i w jakiej konkretnie jednostce fizycznej. Z uwagi na czasowe zachowanie i bezwarunkową determinację oraz fakt, że pracują blisko komponentów sterowniczych, systemy magistrali danych są mało przydatne. Dlatego w celu połączenia wielu przekształco− nych sieci budynku, zastosowany został inny model, który można wdrożyć na wiele poziomów. Dołączyć można do niego obraz, który zawiera zmienną formę wszystkich istotnych danych, jak pozycja, warunki pracy, sygnały drzwi i szybu. Aktualizowane jest to przez sterownie ze stałą przerwą czasową lub poprzez zaprogramowanie na konkretną sytuację. Ogółem, za jednym zamachem, stworzony został interfejs, dzięki któremu, system może działać na wyższym poziomie. Na przykładzie rozwiązania użytego w szpitalu AMC, to zadanie przejmuje Embedded− Device−Server (EPC).

Baza danych kart

 Umieszczono go w obudowie do montażu szyn kątowych, tak żeby można było połączyć go wygodnie w szafie sterowni windy grupowej. Obraz procesu pojedynczych uczestników grupy, został zarejestrowany przez wspólną magistralę danych CAN, przy użyciu CANopen i profilu zastosownia 417, przez centralne EPC. Ta grupa budowlana, wyposażona w łącze CAN i łącze internetowe, przy priorytetowym użyciu TCP/IP, interfejs wprowadza jedynie do sieci budynku. W przedstawionym przykładzie, μClinux zastosowany zostanie jako system pracy w EPC i dlatego obok wypróbowanego TCP/IP−Stack, wykorzystuje też inne, typowe dla Unix zdolności wsparcia powszechnych systemów danych. Ponieważ chodzi o rozwiązanie przemysłowe, które powinno funkcjonować niezawodnie, bezpiecznie i bez zakłóceń przez lata, nie zastosowano żadnych, twardych dysków i ak− tywnego chłodzenia. Zamiast tego, poprzez użycie prawdziwych komponentów „embedded” – pamięci flash i wydajnego mikrokontrolera – osiągnięto maksimum żywotności. EPC wykona więc tylko takie zadania, w których on jeden jest w sieci do dyspozycji świata zewnętrznego przez TCP/IP.

• Urzeczywistnienie i zastosowanie specyficznych dla szpitala kart dla zespołu reanimacyjnego, służby wartowniczej,
  personelu opieki i techników, dostęp do obrazu procesu przez DFÜ300−Stack, aby bazując na sieci, na nadrzędnym poziomie serwera, można
  było zastosować monitoring Win−MOS®300,
• lokalna kopia bazy danych kart, żeby również przy awarii sieci, nadal można było pracować,
• aktualizacja lokalnej bazy danych kart w bieżącym użyciu, przez nadrzędny poziom serwera, bez przerywania przy tym pracy,
• zapisywanie informacji dotyczących czasu trwania, np. używanych w ciągu dnia kart.

W ten sposób każda grupa wind może być samowystarczalna. Przy ewentualnej awarii sieci w budynku, nadal pozostaje zdolna do pracy. W następnych etapie, stworzono kolejny, wyższy poziom serwera, który podsumowuje obraz procesu, rozszerzonego w tym przypadku, o specyficzne dla klienta dane kart. W tym procesie dane te oceniono już pod względem statystycznym. Ponieważ jako forma transmisji w użycie wchodzi internet (przy zastosowaniu IP jako warstwy sieci i TCP jako warstwy transportowej) i nie wykazuje żadnych możliwych do przewidzenia zachowań czasowych, nie może być realizowane żadne bezpośrednie zadanie sterowni. Serwer WinMOS®300 ma do pozyskania więcej zadań i informacji, odnośnie zakłóceń i serwisu, który tymczasowo magazynuje aktualny obraz procesu i dysponuje danymi do wizualizacji komputerowych miejsc pracy (Clients). Poza tym odbiera on komendy i kieruje je dalej, na niższy poziom. Następująca ilustracja powinna to wyjaśnić: Miejsce pracy PCs (Clients) daje użytkownikowi do dyspozycji następujące funkcje:

• blokowanie pięter, wyznaczanie wezwań, włączanie/wyłączanie telefonii,
• aktywacja specjalnego priorytetu helikoptera, który będzie można cofnąć tylko przez ustalone karty, albo po upływie możliwego do nastawienia czasu pozostawania do dyspozycji,
• zmiana priorytetowych przystanków (przypadek pożaru, straż pożarna, prąd w stanie zagrożenia),
• dostęp do menu serwisu każdej sterowni,
• wizualizacja pozycji kabiny, prędkości i wszystkich istotnych sygnałów, włącznie z kręgami bezpieczeństwa,
• przedstawienie zastosowanych kart transpondera oraz dalszych danych pracy.

Na drugim poziomie serwera, wydanymi kartami transpondera zarządza baza danych MySQL. Na poziomie pierwszym (EPC w maszynowni), forma pliku transmituje grupy wind. Dzieje się to albo na polecenie użytkownika na miejscu pracy PC (Client), albo automatycznie, przy ponownym uruchomieniu EPC. Dzięki temu istnieje gwarancja, że wszystkie zmiany (np. typu kart, nazwy użytkownika/numeru osobistego i maski przydzielonej windzie), zostaną przekazane w procesie, żeby wszystkie EPC pozostały również na tym samym miejscu. Obok omówionej już bazy danych MySQL, na drugim poziomie serwera biegnie też monitoring serwera WinMOS®300 jako praca NT i serwera internetowego Apache. Ten zaś, w razie konieczności przeglądu technicznego, udostępnia wybranym klientom z bazy danych rozszerzony Web−Front−End (koniec frontu internetowego). W innych przypadkach, dostęp do danych kart następuje po−  przez zastosowanie serwera Java na dru− gim poziome serwera, który znów otrzy− muje polecenia od klienta na miejscu pra− cy PC. Zastosowanie tego systemu oferuje informacje do opracowania sporządzonych kart, typów kart i przydzielonych wind. Powyższa ilustracja pokazuje po− wierzchnię, jaką użytkownik ma do dyspo− zycji w celu opracowania danych kart. Żeby sporządzić nowe karty, albo przyporządkować istniejące, miejsca pracy (klientów) wyposażone zostały w połączo− ne ze stołem, urządzenie do czytania. Na miejscach pracy przy komputerach, biegnie również monitoring WinMOS®300, który otrzymuje wszystkie dane z drugie− go poziomu serwera i jest odpowiedzialny za wizualizację bieżących urządzeń. Wspierany jest on przez statystyczny moduł w celu zobrazowania czasu oczekiwania na wezwanie, czasu zwłoki zatrzy− mania i ruchu drzwi oraz moduł widoku właściwego położenia urządzeń i warunków ich funkcjonowania. Ochrona dostępu do systemu następuje przez identyfi− kacja nazwy użytkownika i hasła oraz listy adresów IP.

Parametr	Monitoring

Użytkownik bazy danych i użytkownik monitoringu, może zostać umieszczony W obrębie zastosowania WinMOS®300 po to żeby można było mu przydzielać różnego rodzaju uprawnienia. W praktycznym zastosowaniu, konieczne są oczywiście zmiany we właściwym programie sterowania urządzeniami wind. Należą do nich: określenie priorytetów dotyczących czasu gotowości do pracy oraz odpowiednich parametrów. Na tym konkretnym przykładzie, chodzi o dostosowanie czasu gotowości potrzebnego do wezwania helikoptera. Podział zadań na kilka poziomów, pozwa− la na użycie dopasowanych systemów magistrali danych i komponentów oraz ułatwia podział zadań w obrębie zespołu. Absolutnie konieczny jest do tego dokładny układ interfejsu i zastosowanie unormowanych i istniejących już protokołów, których inwestycja w rozwój (tak jak przy CANo− pen CiA417) wspierany będzie przez wspólnotę interesów. Również nazwanie i uwzględnienie osób odpowiedzialnych za klientów końcowych ma ogromne znaczenie, ponieważ drugi poziom serwera nie będzie później już utrzymywany przez przedsiębiorstwo zajmujące się przeglądem technicznym urządzeń wind, tylko przez oddział IT klienta końcowego. Wcześniejsze umowy i ustalenia o prawach ad− ministracyjnych, cechach rozwiniętego So− ftware i gotowość dostępu do sieci, ustalono tak wcześnie, jak to tylko było możliwe. Aby dać klientowi sposobność sprawdzenia zdefiniowanych przez niego kart i reguł w konkretnym projekcie został poczyniony jeszcze jeden krok do przodu. Na modelu czwartej grupy i lokalnej sieci [z uproszczonym serwerem poziomu pierwszego i drugiego jak i dwóch miejsc racy PC (klient)] wspólnie z klientem roz− ważone zostały różne scenariusze. Występujące różnice osiągnięć realnej pracy zostały omówione, a zmiany w dokumentacji i projekcie przeprowadzone. To ważne, bo jak wiadomo praktyka niesie za sobą trudne do przewidzenia zdarzenia i lepiej pomyśleć o nich wcześniej.