Wstęp

Dzisiaj nieco o czym innym, ale nie aż tak innym :). Po raz kolejny odkrywam, że od lat pisze prozą ;).

Nie raz publikowałem tu różne rodzaje diagramów przypadków użycia, które opisują oprogramowanie, ale tym razem ‘aktorem’ nie jest ani człowiek ani inna aplikacja, dzisiaj aktorem jest urządzenie elektromechaniczne. Otóż od czasu do czasu miewam projekty gdzie ‘aktorem’ jest “żelastwo”. Najczęściej są to projekty związane z zaawansowanymi systemami sterowania produkcją, jednak to nie jedyne takie miejsce.

Coraz częściej czytamy o “Internecie Rzeczy” (ang. IoT, Internet of Things) a to nic innego jak mechatronika, a czym jest mechatronika? Jedna z uczelni amerykańskich (przypadkiem wyskoczyła jako na początku listy w google) podaje na swojej stronie:

Mechatronics is a multidisciplinary field that combines several types of engineering?electrical, computer, and mechanical?and refers to the skill sets needed in the contemporary, advanced automated manufacturing industry. At the intersection of mechanics, electronics, and computing, mechatronics specialists create simpler, smarter systems. Mechatronics is an essential foundation for the expected growth in automation and manufacturing.Mechatronics is an industry buzzword synonymous with robotics and electromechanical engineering. Robotics, control systems, and electro-mechanical systems fall under mechatronics. (What is Mechatronics? | Michigan Technological University)

W uproszczeniu jest to interdyscyplinarna działalność, która łączy kilka rodzajów inżynierii: elektrycznej, komputerowej i mechanicznej. W tym obszarze powstają prostsze, inteligentniejsze systemy, gdyż wiele urządzeń mechanicznych można zastąpić prostszymi konstrukcyjnie podsystemami komputerowymi (komputer to procesor, pamięć i program wraz z interfejsami, autorzy z obszaru filozofii informatyki używają określenia: komputer jako uniwersalny mechanizm ). Mechatronika to jednak ostatnio głównie modne hasło branżowe (ang. buzzword), będące synonimem robotyki i inżynierii elektromechanicznej.

Wielu autorów publikujących w obszarze mechatroniki pisze we wstępach i streszczeniach: Systemy mechatroniczne charakteryzują się synergiczną interakcją między ich elementami pochodzącymi z różnych dziedzin technologii. Te interakcje umożliwiają systemowi osiągnięcie większej liczby funkcji niż suma funkcji cechy jego składników rozpatrywane niezależnie. Interdyscyplinarność mechatroniki można przedstawić tak:

Autor powyższego tak pokazuje różnicę pomiędzy tradycyjnym a mechatronicznym podejście do projektowania:

Tradycyjne metody projektowania są już niewystarczające. Dlatego coraz więcej inżynierów korzysta z rozszerzenia języka UML do celów szerzej rozumianej inżynierii, jakim jest język SysML , .

Ogólnie cykl wytwarzania urządzeń mechatronicznych jest opisywany np. tak :

Jak widać, cały cykl projektowy jest procesem interdyscyplinarnym.

Mechatronika i notacja SysML ma swoje początki w latach 90-tych. Modele w tej notacji powstawały już w firmie Boeing . Od tamtej pory powstało wiele publikacji na ten temat, w tym także opisy dobrych praktyk jakimi są wzorce projektowe . Można spotkać coraz częściej publikacje na temat stosowania metod projektowania opartych na SysML .

Moim celem było tu zwrócenie uwagi na tę w sumie nową dziedzinę inżynierii, ważne by nie utożsamiać jej jedynie z robotyką, bo było by to ogromne uproszczenie, co mam nadzieję pokazałem powyższymi przykładami. Po drugie rosnąca złożoność produktów zmusza do stosowania metod ograniczających liczbę analizowanych detali na wczesnych etapach opracowania produktów i projektowania .

Prosty przykład

Na zakończenie, prosty diagram opisujący pralkę:

Na powyższym diagramie pokazano schemat blokowy hipotetycznej pralki, ze wskazaniem, które jej elementy będą realizowane przez komponent będący komputerem. Można sobie wyobrazić, że programator mechaniczny zastąpiono komputerem (jest to już dość powszechne). Ale można też sobie wyobrazić, że pralka sama komunikuje nam stan pracy, kolejne fazy prania i ewentualnie prosi o reakcję w przypadku niestandardowej sytuacji. Schematy takie powstają, by już na tym etapie projektowania możliwe było określenie wymagań na to oprogramowanie. Zrozumienie działania całości tego systemu to klucz do skutecznego projektowania i testowania oprogramowania zanim jeszcze powstanie samo urządzenie. Oczywiście projektowanie pralki jakie jako takie ma głęboki sens.

Warto wiedzieć i rozumieć jak są budowane interfejsy pomiędzy komputerem a mechanicznymi elementami takiego systemu (np. termostat): interfejsy dostarczają producenci podzespołów, komputer “widzi” inne urządzenia jako obszary pamięci.

SLIM (Systems LIfecycle Management)

Polecam też artykuł na temat integracji opisanych wyżej metod i narzędzi do modelowania takich jak notacja SysML i pakiet CASE (np. Visual Paradigm, który posłużył mi tu wykonania modeli):

SLIM (Systems LIfecycle Management) jest środowiskiem dla zintegrowanej inżynierii systemów opartej na modelach, notacji SysML (OMG Systems Modeling Language) i produktach PLM (Product Lifecycle Management). Dzięki temu podejściu inżynierowie złożonych systemów mogą opracowywać i zarządzać wysokopoziomową architekturą systemu/produktu w SysML i jednocześnie łączyć się, komunikować i synchronizować ze szczegółowymi wymaganiami, częściami (zestawienia materiałów i CAD), modelami symulacyjnymi (MATLAB/Simulink, Mathematica, CAE) i złożonymi strukturami danych, które są wersjonowane i kontrolowane w systemach PLM klasy korporacyjnej (takich jak Teamcenter i Windchill) oraz obiektowych / relacyjnych bazach danych (takich jak MySQL).

(źr.: Enabling MBSE by integrating SysML with PLM, CAD/CAE, Databases)

Źródła