Schneider Electric udostępnia źródła XML PLCopen

Clive Smith, reprezentujący Schneider Automation, zaprezentował Elco van der Walowi, dyrektorowi zarządzającemu PLCopen, źródła XML do konwersji graficznych języków PLC na format XML. Dodatkowo dołączono wstępny szkic 49 stronicowej specyfikacji technicznej „XML Formats for Graphical Languages” uszczegóławiającej implementację tych źródeł.
Ofiarowane przez Schneidera „XML sources” są zestawem definicji opisujących jak elementy trzech graficznych języków PLC – Function Block Diagram (FBD), Sequential Function Char (SFC) i Ladder Diagram (LD) – mogą być opisywane przy pomocy XMLa. Udostępniona członkom PLCopen dokumentacja zostanie wewnętrznym dokumentem dopóki członkowie nie zdecydują co z nią zrobić. Mówi się, że dostarcza ona definicje XML wszystkich elementów we wszystkich trzech językach graficznych.
Smith stwierdził, że Schneider Automation od pewnego czasu pracowała nad źródłami XML będącymi sposobem na połączenie oprogramowania różnych produktów PLC w swojej firmie.
Schneider aktualnie wspiera marki takie jak April, AEG, Modicon, Telemecanique PLC oraz w Stanach Zjednoczonych SyMax i Square D.
Van der Wal powiedział, że w rezultacie udostępnienia dokumentacji przez Schneidera zostanie powołane nowy komitet techniczny o nazwie TC6-XML aby przyjrzał się ofiarowanym materiałom.
„W praktyce oznacza to, że źródła XML, w chwili obecnej udostępnione przez pojedynczą firmę, zostaną przetestowane i zaadaptowane przez znaczny zestaw narzędzi i dostawców. Doskonale współgra to z ideą istnienia XMLa i będzie szczególną korzyścią dla języków graficznych.”
Komitet techniczny TC6-XML odbędzie pierwsze spotkanie 26 czerwca w biurach Schneider Seligenstadt w Niemczech. Obecnych będzie 15 do 20 reprezentantów firm związanych z PLC i oprogramowaniem. Propozycja udostępnienia materiałów przez Schneidera została złożona podczas generalnego zebrania PLCopen w czerwcu 2001 r. na Infoteam w Niemczech.
„Schneider Electric położył fundamenty” – komentuje van der Wal. „Musimy jeszcze sprawdzić jak łatwo będzie się dało je zastosować w naszych systemach. To będzie właśnie decyzja komitetu TC6. Może on uznać dokument za prawie kompletny i wymagający tylko kilku dodatków, lub może chcieć utworzyć indywidualny zespół by przyjrzeć się dokładniej pewnym aspektom. Definitywnie nie będziemy niczego publikować przed zakończeniem czerwcowego spotkania. Z całą pewnością będzie to co najmniej dobra informacja zwrotna dla Schneidera”.

Cele PLCopen.
Celem IEC61131 było zapewnienie harmonizacji języków programowania PLC pomiędzy różnymi markami, a nie konkretne dostarczenie przenośności kodu pomiędzy kontrolerami różnych dostawców. Przenośność była bardziej zadaniem PLCopen.
Jednak ambicje przenośności PLCopen były trudne do osiągnięcia i w rzeczywistości tylko częściowo zrealizowane przez wymianę kodu skompilowanego w Instruction List (IL). Bardzo trudno jest przenieść kod z jednego języka graficznego na inny i próby osiągnięcia tego zawierały IL wraz z kombinacją C i C++ lub tylko C. „Prawdopodobnie jest więcej kodu języka C pomiędzy PLC niż czegokolwiek innego” – przyznaje van der Wal.
Jednocześnie stwierdził, że członkowie PLCopen są bardzo zainteresowani specyfikacją XML, ponieważ umożliwia ona sposób na rozwiązanie problemu wymiany pomiędzy językami graficznymi. Problem ten ma 10 lat i nadal nie jest rozwiązany.
„Jeśli stworzy się program graficzny w jednym środowisku, następnie eksportuje go do innego, to oczekuje się podobnego programu” – powiedział van der Wal. „Tak jak to tylko możliwe konstrukcja graficzna powinna być podobna na obu systemach.”
„Weźmy na przykład FBD. Dla FBD oznacza to, że rozmiar, pozycja, kolejność oraz sposób zestawienia połączeń powinny być przeprowadzane w ten sam sposób. Aby to umożliwić potrzeba znacznej informacji graficznej daleko wykraczającej poza to, co IL lub jakikolwiek kompilowany kod jest w stanie dostarczyć.”
Następny krok: „Jako że XML może być zaprezentowany w dowolnej przeglądarce, oznacza to że będzie ona w stanie ‘zobaczyć’ taki sam program graficzny. Nie może ona zmienić programu, ponieważ nie jest edytorem. Ale jeśli zachowa się program w kodzie XML na docelowym systemie można sprawdzić go przy pomocy dowolnej przeglądarki.” – powiedział.
„Ponadto niezależny kod XML daje możliwość posiadania graficznego edytora oddzielnie od części kompilatora. Edytorem może być np. Microsoft Visio, a kompilatorem może być komponent działający gdzieś w sieci, lub nawet na PLC” – dodał.
„Podsumowując, jeśli osiągniemy porozumienie z pewnością stworzy to bazę dla różnych architektur stosowanych już teraz.”