wersja mobilna
Online: 475 Niedziela, 2016.09.25

Biznes

Problemy z Autosarem

czwartek, 10 kwietnia 2008 16:07

Autosar, czyli AUTomotive Open System ARchitecture jest otwartym standardem, który ma za zadaniem zdefiniowanie architektury oprogramowania wykorzystywanego w przemyśle motoryzacyjnym. Powstaje on w wyniku współpracy producentów pojazdów, dostawców komponentów oraz projektantów związanych z tą branżą.

Organizacja pracująca nad Autosarem zrzesza między innymi takie firmy jak: BMW, Bosch, Daimler Chrysler, Ford Motor, General Motors, Siemens, Toyota, Volkswagen, Delphi, Denso, Freescale, Fujitsu, Hitachi, Daewoo oraz wiele innych. Podstawową przyczyną, dla której tak wiele różnych firm postanowiło połączyć siły jest narastający problem ze sterowaniem coraz bardziej innowacyjnymi i skomplikowanymi aplikacjami w pojazdach. W rezultacie doszło do sytuacji, w której jedynie znaczący przełom technologiczny mógłby umożliwić spełnienie wzrastających oczekiwań klientów.

Problemy i cele

Problemy dotyczą zwłaszcza producentów pojazdów najwyższej klasy oraz ich bezpośrednich dostawców. Wymienić należy konieczność wprowadzania w życie uwarunkowań prawnych w zakresie bezpieczeństwa i ochrony środowiska. Kluczowe stało się także spełnienie rosnących wymagań co do bezpieczeństwa i prostoty obsługi oraz wspomagania kierowania, w tym konkretnych aspektów dotyczących detekcji i unikania niebezpiecznych sytuacji oraz nawigacji korkach ulicznych. W związku z tym, twórcy standardu postawili przez sobą kilka konkretnych celów. Jest to przede wszystkim określenie implementacji i standaryzacja podstawowych funkcji systemu w taki sposób, aby były one dostępne w różnych pojazdach i na różnych platformach. Wymaga to oczywiście integracji modułów funkcjonalnych wielu producentów. Celem jest również ułatwienie napraw, zwiększenie wykorzystania powszechnie spotykanych urządzeń oraz umożliwienie aktualizacji oprogramowania w czasie eksploatacji pojazdu. Podsumowując Autosar w zamierzeniu ma służyć jako platforma, na bazie której w przyszłości będą implementowane aplikacje wykorzystywane w pojazdach. Obecnie zaś celem standardu jest minimalizacja barier występujących pomiędzy różnymi funkcjonalnymi obszarami. Dąży się więc do sytuacji, w której możliwe będzie przenoszenie funkcji pomiędzy poszczególnymi węzłami kontrolnymi w systemie, praktycznie niezależnie od stosowanego sprzętu.

Struktura

Paradoksalnie, pościg za różnymi opcjami w obrębie platformy programowej Autostar prowadzi do niezgodności oprogramowania. Sprawia to, że standard nie spełnia wysokich wymagań, które są przed nim stawiane. Ironia tej sytuacji polega na tym, że Autosar powstał właśnie po to, aby można było zapanować nad złożonością i różnorodnością oprogramowania w pojazdach. Głównym celem tego standardu, aktualnie dostępnego w wersji 3.0, jest uniezależnienie funkcji zaimplementowanych w oprogramowaniu od konkretnych mikrokontrolerów oraz elektronicznej jednostki sterującej (ECU) poprzez pośrednie i ściśle zdefiniowane warstwy. Standard jest podzielony na warstwę oprogramowania, warstwę środowiska uruchomieniowego, która zapewnia możliwości komunikacji i wymiany danych jednostce ECU oraz warstwę oprogramowania podstawowego. Celem twórców Autosara jest nie tylko standaryzacja najważniejszych funkcji systemu, ale również stworzenie platformy umożliwiającej integrację oprogramowania pochodzącego od różnych producentów. Zwiększyłoby to efektywność współdziałania pomiędzy firmami związanymi z tą branżą.

Naciski

Pojawiają się jednak pierwsze przeszkody związane z dużą liczbą firm, które współpracują przy tworzeniu standardu współpracuje tak wiele różnych firm. Jednym z głównych zagadnień jest kwestia rozstrzygnięcia tego, która wersja standardu powinna zostać zaimplementowana. Zarówno producenci OEM, jak i bezpośredni dostawcy, wywierają różnego rodzaju naciski. Celem tych działań jest zaimplementowanie wybranych funkcji, które nie zawsze są pożądane z punktu widzenia pozostałych współtwórców standardu.

Na przykład, standard określa trzy podejścia, w których na etapie projektowania twórcy muszą zobowiązać się do realizacji określonego typu komunikacji. W danym typie sprecyzowano topologie oraz protokoły używane przez ECU. Jednak w związku z sugestią szwedzkiego koncernu Volvo, standard przewiduje dodatkowe opcje komunikacji. I mimo, że zapewniają one wszystkim projektantom najwyższy stopień elastyczności, jedynie pomysłodawcy są w stanie wykorzystać te funkcje. W związku z tym, według ekspertów rozszerza to niepotrzebnie standard kosztem jego przejrzystości. W konsekwencji wielu dostawców oferuje po prostu różne wersje danego standardu.

Podsumowanie

Na kongresie Euroforum poświęconym oprogramowaniu stosowanemu w pojazdach, swój pomysł przedstawiła również firma Bosch. Koncepcja dotyczyła modułów związanych z detekcją potencjalnego obiektu zderzenia. Pomysł ten wzbudził spore kontrowersje wśród uczestników. Padały pytanie przede wszystkim dotyczące otwartości oraz kompletności takiej implementacji. Odpowiedź przedstawicieli Boscha nie była jednoznaczna. Z jednej strony zapewniali oni o swojej otwartości, a z drugiej sami zauważali, że może się zdarzyć sytuacja, w której nie wszystkie zakładane funkcje będą dostępne. W trakcie dyskusji przyznano również, że integracja modułów różnych producentów może okazać się w takim wypadku bardzo skomplikowana. W ten sposób potwierdzony zostaje fakt, że pełna realizacja technologii plug and play w przypadku standardu Autosar jest nierealna. W związku z tym konieczny staje się kompromis. Rozwiązaniem mogą stać się systemy tworzone na zamówienie. Realizują one jedynie wybrane elementy standardu i mogą zostać zaimplementowane w sposób efektywnie wykorzystujący zasoby sprzętowe. Jednak wysokie ceny dedykowanych rozwiązań sprawiają, że z pewnością wielu dostawców wybierze raczej ograniczone wersje oprogramowania, które będą się różnić w znaczący sposób w zależności od klienta i aplikacji.

Problemem jest także spełnienie przez oprogramowanie Autosar wymagań dotyczących pracy w czasie rzeczywistym, pomimo, że teoretycznie są takie funkcje. Trudność występuje na etapie współpracy firm OEM z producentami. W większości przypadków przedstawiciele firm OEM nie mają informacji na temat istotnych parametrów związanych z przetwarzaniem w czasie rzeczywistym. Problemem jest także to, że Autosar jest przeciwieństwem tradycyjnego modelu, w którym firmy OEM definiują i rozwijają pakiety programowe, podczas gdy producenci dostarczają i integrują sprzęt. Tymczasem celem standardu jest stworzenie, na wzór komputerów PC, modelu w którym oprogramowanie jest dostarczane przez trzeciego partnera. Zdaniem ekspertów taki model nigdy nie odniesie dużego sukcesu. Proces integracji standardu nie jest jeszcze zakończony i szacuje się, że zajmie to jeszcze kilka lat. Część analityków jest zdania, że masowa produkcja komponentów zgodnych z tym standardem rozpocznie się nie wcześniej niż w 2010 roku.

Monika Jaworowska

 

World News 24h

niedziela, 25 września 2016 16:06

US-based Rockwell Automation has recently filed a complaint with the US ITC against Germany-based Smart Software Solutions and Taiwan-based industrial computing device maker Advantech alleging 3S's CoDeSys software, used in industrial automation control, infringes on eight patents. Advantech adopts CoDeSys in its hardware.

więcej na: www.digitimes.com