Jeśli pracujesz w chłodnictwie przemysłowym lub HVAC, niemal na pewno programowałeś sterownik CAREL. Ale czy zastanawiałeś się kiedyś, co tak naprawdę działa pod powierzchnią płyty c.pCO?

Spędzamy dni w c.suite, przeciągając zmienne na wyświetlacze, konfigurując linie Modbus i wgrywając aplikacje. Ale architektura firmware działająca wewnątrz tych sterowników to fascynujący świat inżynierii embedded. Pokażę Ci, co napędza c.pCO — koncentrując się na publicznie znanych komponentach i aspektach, które każdy inżynier pracujący z tymi sterownikami może zaobserwować.

Serce: System operacyjny czasu rzeczywistego

W sercu każdego sterownika c.pCO działa embOS firmy SEGGER — priorytetowy, wywłaszczający system operacyjny czasu rzeczywistego (RTOS). W odróżnieniu od Linuxa czy Windowsa, RTOS gwarantuje deterministyczne zachowanie: każde zadanie wykonuje się w ściśle określonych ramach czasowych.

Dlaczego to ma znaczenie? Pomyśl, co robi Twój sterownik w instalacji chłodni. Pętla regulacji kontrolująca sprężarki i zawory rozprężne absolutnie nie może czekać, aż załaduje się strona webowa albo zakończy się cykl odpytywania Modbus. embOS zapewnia, że zadania o wysokim priorytecie natychmiast wywłaszczają te o niższym priorytecie — poprzez przełączanie zadań sterowane przerwaniami, semafory zapewniające bezpieczny dostęp do danych z wielu wątków oraz timery programowe — wszystko w maleńkim footprincie odpowiednim dla mikrokontrolera.

Stos oprogramowania: Na barkach SEGGER-a

CAREL nie budował wszystkiego od zera. c.pCO wykorzystuje rodzinę sprawdzonych modułów middleware SEGGER, które współpracują bezproblemowo: embOS do zarządzania zadaniami, embOS/IP do sieci TCP/IP, emFile do operacji na systemie plików i emUSB do obsługi USB.

Każdy moduł ma czterowarstwową architekturę: rdzeń niezależny od sprzętu, warstwa konfiguracji, Board Support Package (BSP) oraz warstwa sterowników specyficzna dla CPU. Dzięki temu CAREL może przenieść tę samą logikę wyższego poziomu na różne platformy sprzętowe, adaptując jedynie niższe warstwy — elegancka inżynieria, gdzie liczy się każdy bajt RAM.

Co ciekawe, stos SEGGER-a nie pokrywał wszystkich potrzeb CAREL. Obsługa portów szeregowych (kluczowa dla komunikacji RS485 fieldbus) nie była częścią pakietu SEGGER, więc CAREL opracował własny moduł komunikacji szeregowej od podstaw. Podobnie napisali niestandardowy sterownik SPI specjalnie do komunikacji z wbudowanym wyświetlaczem. To właśnie takie praktyczne adaptacje tworzą prawdziwy produkt z komponentów middleware.

System plików: Więcej niż tylko przechowywanie

Można by pomyśleć, że PLC nie potrzebuje systemu plików, ale c.pCO przechowuje sporo na swojej pamięci NAND flash: binaria aplikacji, pliki konfiguracyjne, logi, strony serwera WWW i pakiety aktualizacji. emFile firmy SEGGER zapewnia wbudowany system plików oparty na FAT, co oznacza, że możesz podłączyć pendrive’a i Twój PC odczyta pliki bezpośrednio.

Z perspektywy inżynierskiej interesujące jest zarządzanie ograniczeniami. Pamięć na uchwyty plików i bufory jest alokowana statycznie w czasie kompilacji — bez dynamicznej alokacji — ponieważ w systemie embedded obsługującym Twoją chłodnię, nieudana alokacja pamięci w runtime mogłaby oznaczać zawieszony sterownik i zepsute produkty. Journaling zapewnia spójność systemu plików nawet po nieoczekiwanych przerwach zasilania. Dla każdego, kto stracił konfigurację sterownika przez awarię zasilania na starszej platformie, to znaczące usprawnienie.

Sama pamięć NAND flash dodaje złożoności: ograniczona liczba cykli zapisu/kasowania wymaga wear leveling, podobnie jak u producentów SSD — z tą różnicą, że CAREL rozwiązuje to w ramach kilobajtów RAM.

Runtime aplikacji: Gdzie Twój Structured Text ożywa

Kod, który piszesz w Structured Text (lub FBD, lub Ladder) w c.suite, nie działa bezpośrednio na sprzęcie. Działa wewnątrz runtime’u zgodnego z IEC 61131-3 — konkretnie ISaGRAF firmy Rockwell Automation. Ten runtime obsługuje wszystkie pięć języków programowania IEC 61131-3 i wykonuje Twoją aplikację w klasycznym cyklu skanowania PLC: odczyt wejść, wykonanie programu, zapis wyjść.

Tu robi się interesująco dla tych z nas, którzy wgrywali aplikacje na sterowniki c.pCO: kiedy kompilujesz projekt w c.suite, wynikiem jest plik z rozszerzeniem .ap1. Jeśli kiedykolwiek zastanawiałeś się, czym właściwie jest ten plik — to zasadniczo przemianowane archiwum ZIP zawierające skompilowany kod aplikacji, tabele konfiguracyjne ISAI oraz manifest z sumami kontrolnymi CRC. Manifest wymienia wszystkie komponenty i ich sumy kontrolne, a sterownik weryfikuje CRC16 każdego pliku (plus CRC32 samego ZIP-a) przed zaakceptowaniem aktualizacji. Jeśli cokolwiek się nie zgadza, sterownik odrzuca pakiet. Dlatego wgrywanie aplikacji albo kończy się pełnym sukcesem, albo czysto się nie udaje — nie ma stanu częściowego wgrania.

Konsola Telnet: Twój ukryty przyjaciel do debugowania

Oto szczegół, o którym wielu programistów c.pCO nie wie: sterownik uruchamia serwer telnet, który daje dostęp do wbudowanego shell-a wiersza poleceń. To nie jest prosty wyświetlacz statusu — to pełna konsola diagnostyczna, w której możesz sprawdzić stan działania sterownika, kontrolować status systemu i wchodzić w interakcję z firmware w sposób, którego narzędzia graficzne nie oferują.

Shell zawiera nawet narzędzia wiersza poleceń zbudowane na bazie zlib — tej samej biblioteki kompresji open-source używanej do obsługi pakietów aktualizacji .ap1. Dostęp do tej konsoli może być nieoceniony podczas uruchomienia lub rozwiązywania problemów z komunikacją w terenie, szczególnie gdy nie masz pod ręką c.suite.

Komunikacja: Każdy protokół to osobne zadanie

Współczesne sterowniki c.pCO nie pracują w izolacji. Komunikują się przez Modbus, BACnet, własnościowy protokół CAREL i inne. Elegancja implementacji CAREL polega na tym, że każdy protokół działa jako osobne zadanie RTOS, a każda instancja protokołu na porcie to osobna instancja zadania z własnym izolowanym kontekstem pamięci — bez zmiennych globalnych współdzielonych między protokołami.

Architektura zawiera warstwę pomostową (bridging layer), która synchronizuje zmienne runtime’u z zadaniami komunikacyjnymi poprzez precyzyjnie taktowane haki: wartości zewnętrzne są wstrzykiwane na początku każdego cyklu skanowania, a zaktualizowane wyjścia eksportowane na końcu. Dzięki temu Twoja aplikacja zawsze widzi spójny snapshot swoich I/O podczas wykonania. To również powód, dla którego zapis Modbus nie działa w środku cyklu — czeka na następny punkt synchronizacji.

Warto też zwrócić uwagę na zarządzanie awariami. Przy komunikacji z urządzeniami slave po linii szeregowej, master używa mechanizmu timeout-and-retry. Jeśli urządzenie przejdzie offline, opóźnienie oblicza się jako timeout pomnożony przez liczbę prób, a system obsługuje odpytywanie priorytetowe — zmienne o wysokim priorytecie z ważnych urządzeń są odpytywane częściej niż dane diagnostyczne o niskim priorytecie.

Architektura I/O: Płyta wewnątrz płyty

Jednym z bardziej zaskakujących aspektów konstrukcji c.pCO jest sposób zarządzania lokalnym I/O. Główny procesor nie odczytuje bezpośrednio sond temperatury ani nie steruje wyjściami przekaźnikowymi. Zamiast tego płyta sterownika zawiera wiele mikroprocesorów STM8 (do 5, w zależności od rozmiaru płyty), które obsługują analogowe i cyfrowe I/O przez dedykowane układy frontend ChipIO.

Główny CPU komunikuje się z procesorami STM8 przez lokalną magistralę szeregową z prędkością 115200 baud, używając zmodyfikowanego protokołu Modbus RTU z niestandardowymi komendami dla optymalizacji szybkości. Dedykowane zadanie ciągle odpytuje chipy STM8 o dane wejściowe i wysyła komendy wyjściowe przez kolejkę wiadomości. Broadcast timera synchronizacyjnego co 2 sekundy koordynuje wszystkie procesory I/O.

Rozmiar płyty determinuje topologię I/O: “mały” c.pCO ma 2 procesory STM8 i 1 ChipIO, podczas gdy model “extralarge” ma 5 STM8 i 2 ChipIO. Ta konfiguracja sprzętowa jest przechowywana w zabezpieczonym przed zapisem EEPROM I2C na płycie bazowej, zapisywanym podczas produkcji i następnie trwale zaplombowanym. Firmware odczytuje ten deskryptor topologii przy starcie, aby dokładnie wiedzieć, jakie możliwości I/O są fizycznie dostępne.

Watchdog: Bo niezawodność nie podlega dyskusji

W chłodnictwie zawieszony sterownik może oznaczać tysiące euro strat w zepsutym towarze. c.pCO implementuje dwuwarstwowy system watchdog. Sprzętowy Independent Watchdog Timer (IWDT) działa z własnego źródła zegara i nie może być zatrzymany — nawet przez reset programowy. Na wierzchu znajduje się watchdog programowy zaimplementowany jako tablica liczników odliczających w dół, po jednym na każdy krytyczny moduł. OS dekrementuje wszystkie liczniki raz na sekundę i odświeża sprzętowy watchdog tylko wtedy, gdy żaden nie przekroczył zera.

Oto praktyczny szczegół, który każdy programista c.pCO powinien znać: aplikacja wgrana bez skonfigurowanych I/O wywoła watchdog. Moduł I/O jest jednym z krytycznych modułów chronionych przez watchdog programowy, i jeśli nie ma czym zarządzać, nie odświeży swojego licznika — co doprowadzi do restartu systemu. To nie jest błąd, to funkcja bezpieczeństwa.

Zmienne retencyjne: EEPROM z siatką bezpieczeństwa

Kiedy deklarujesz zmienne retencyjne w aplikacji ISaGRAF, możesz zakładać, że są po prostu zapisywane do jakiejś pamięci. Rzeczywistość jest bardziej wyrafinowana. c.pCO używa EEPROM z modułem “safe”, który dodaje weryfikację CRC na poziomie bloków i utrzymuje kompletną kopię lustrzaną wszystkich danych. Na płytach c.pCO z dwoma chipami EEPROM, mirror jest przechowywany na drugim chipie dla maksymalnej niezawodności. Na mniejszych platformach jak pCOmini z jednym chipem, mirror zajmuje górną połowę tego samego chipa.

Dla zmiennych nieulotnych wymagających częstych zapisów (gdzie zużycie EEPROM byłoby problemem), istnieje oddzielna ścieżka NVRAM wykorzystująca pamięć podtrzymywaną bateryjnie — z chipa zegara czasu rzeczywistego lub dedykowanego chipa FRAM.

USB: Port o podwójnej osobowości

Kiedy podłączasz c.pCO przez USB, sterownik prezentuje się jako urządzenie złożone z dwoma interfejsami: CDC (Communication Device Class) do pobierania aplikacji — zasadniczo wirtualny port szeregowy — oraz MSD (Mass Storage Device) do dostępu do systemu plików flash. To sprytny trick: ten sam port USB obsługuje zarówno programowanie, jak i transfer plików.

Jedna ważna uwaga, na którą natykają się inżynierowie w terenie: gdy aktywna jest pamięć masowa USB, ten sam wolumin flash nie może być zamontowany jednocześnie przez sterownik i PC. Oznacza to, że serwer WWW i serwer FTP przestają działać, gdy USB jest podłączone. To ograniczenie na poziomie systemu plików, nie błąd.

Dlaczego to ma znaczenie

Zrozumienie tego, co kryje się pod interfejsem c.suite, czyni Cię lepszym inżynierem HVAC/R. Gdy wiesz, że synchronizacja zmiennych następuje tylko na granicach cyklu, rozumiesz timing komunikacji. Gdy wiesz, że nie ma sprzętowej ochrony pamięci między zadaniami, rozumiesz, dlaczego nieostrożna operacja na stringu może zawiesić cały sterownik. Gdy wiesz o journalingu systemu plików, rozumiesz, dlaczego sterownik odzyskuje się gracefully po przerwie zasilania — ale może stracić ostatnie kilka sekund zalogowanych danych.

Następnym razem, gdy wgrywasz plik .ap1 na c.pCO, poświęć chwilę na docenienie warstw inżynierii, które to wszystko umożliwiają — od bootloadera sprawdzającego integralność CRC, przez RTOS żonglujący tuzinem równoczesnych zadań, po runtime ISaGRAF interpretujący Twój Structured Text. To imponujący stos, zbudowany celowo dla niezawodności w środowiskach, gdzie ma to największe znaczenie.