Военната / аерокосмическата платформа за оперативна съвместимост предизвиква дизайнерите на системи

Arturo Intelisano - Interview (Юли 2019).

$config[ads_text] not found
Anonim

Широкоприетите OSA търсят подобрено стандартизирано управление на системата

С Джърри Гипър
Изпълнителен директор
VITA
www.vita.com
Повишената сложност на електронните системи в големите отбранителни платформи е вдъхновила няколко инициативи на отворените системи (OSA), които да засилят играта си. Тъй като работните групи от тези инициативи си сътрудничат в стратегиите за решаване на останалите предизвикателства, продължават да се появяват съвпадащи решения за високопроизводителни вградени изчислителни системи.

Министерството на отбраната не осигурява стандартизирана рамка за отворена архитектура за общи услуги вградени системи. Това принуждава програмите да търсят в търговския свят решения. Например, много военни клонове имат инициативи, които се развиват в рамките на модула за оперативна съвместимост, поддържаемост, откритост, използваемост и надеждност на ОСА.

Тези инициативи използват няколко различни OSA за бордови и системни фактори. Програмите разглеждат много различни подходи, както е подходящо (не противоречиви); няма "една архитектура, която да ги управлява всички". Всяка от тези инициативи има поне една обща цел: оперативна съвместимост. Но тази сама цел е предизвикателство.

Многобройни инициативи, свързани с ОСА, включват активни работни групи, които да обсъждат, разработват и прилагат стратегии. В Таблица 1 са изброени ключови инициативи за приложения за отбрана, които прилагат OSA.

Таблица 1: Съответни инициативи на OSA със стратегии за управление на системата, които са наложителни за оперативно съвместимите модули. Източник на таблица: VITA.

инициатива спонсор Мисия
Проектът TENA интегрира мрежата за подобрена телеметрия (iNET) Център за тестване на ресурси и управление (TRMC) и подкрепен от Съвместния екип на САЩ TENA позволява бърза и рентабилна работа по оперативна съвместимост между диапазони, съоръжения и симулации, както и насърчаване на повторното използване на разнообразните ресурси и развитието на системите.
Модулен подход за отворени системи (MOSA)Министерство на отбраната (DoD)MOSA на DoD е да проектира системи с много сплотени, слабо свързани и разделящи се модули, които могат да се конкурират отделно и да се придобият от независими доставчици.
Автомобилна интеграция за C4ISR / EW оперативна съвместимост (VICTORY) промишленост Военна интеграция на електромобилите на земята.
Модулна отворена радиотехническа архитектура (MORA)ВИКТОРИЯ, армия CERDEC I2WDРазширява VICTORY да поддържа радиочестотни (RF) системи.
Функционална среда за бъдещи въздушни способности (FACE) Отворена група Софтуерен стандарт на правителството и бизнес стратегия за придобиване на достъпни софтуерни системи, които насърчават иновациите и бързото интегриране на преносими възможности в глобалните програми за отбрана.
Архитектура на отворените системи на сензори (SOSA)Отворена група, FACEПозволява на правителството и индустрията съвместно да разработват отворени стандарти и най-добри практики, за да дадат възможност, да подобрят и ускорят внедряването на достъпни, способни, оперативно съвместими сензорни системи.
Съвместна обща архитектура - Системи на бордовата мисия

Отворената група,

американска армия

Създаване на FACE.
Технология на отворените системи за хардуер (HOST)NAVAIRОпределя виртуалните и физическите интерфейси към хардуера, така че да може да се реализира оперативната съвместимост и повторното използване на хардуерните компоненти.

Широкостта на базираните на стандарти решения прави много трудно да се осигури оперативната съвместимост, необходима за проектиране на платформи с дълъг жизнен цикъл, които обработват продукти от различни източници. Една от най-големите проблемни области е стандартизирана платформа, система или стратегия за управление на шасито, която поддържа различните стандарти в играта днес.

Управлението на системата и оперативната съвместимост е липсваща връзка
Управлението на системата включва много задачи и обикновено е мащабируемо, за да съответства на сложността на платформата. Типичните задачи включват диагностика (при стартиране и по време на работа), хардуерни запаси, наблюдение и измерване на наличността на системата, софтуерни инвентаризации и инсталации, антивирусен и анти-злонамерен софтуер, мониторинг на дейностите на потребителя, мониторинг на капацитета, управление на сигурността, капацитет на мрежата и мониторинг на използването, анти-манипулационен мениджмънт и др.

За съжаление функционалността за управление на системата често липсва или е недостатъчна в много от често използваните стандарти. За да се преодолее тази пропаст, организациите за разработване на стандарти, като VITA и Open Group, работят по решенията, както и доставчиците на бордове и службите за отбранителни програми.

Предизвикателството за оперативна съвместимост е както хардуерен, така и софтуерен проблем. От гледна точка на хардуера, предпочитат се решения на OSA, които дават възможност за оперативна съвместимост, без да се предписва специфичен хардуерен дизайн или внедряване. Това освобождава дизайнерите да осъществяват управление с някое от разнообразието от универсални процесори или FPGA или друг хардуер.

От страна на софтуера стандартът за управление на системата трябва да поддържа достъп и използваемост на всички данни, свързани със системата в даден модул. Освен това тя трябва да осигури стандартизиран метод за събиране на данни за анализ, който да подпомогне управлението на системата и шасито. И накрая, трябва да се определи стандартизиран набор от основни услуги (интерфейси и структури от данни), които осигуряват обща рамка за системна интеграция. Колкото повече данни могат да бъдат събрани, толкова по-добре и може да бъде оставено на дизайнера да изпълни това, от което се нуждаят. Същевременно стандартът за управление на системата не трябва:

  • Предписвайте дизайн, логика или по друг начин възпрепятствайте иновациите или изпълнението на уникални специфични за платформата изисквания. Чувствителният характер на отбранителните платформи често означава, че се изискват творчески свободи.
  • Имайте зависимости по отношение на използването на операционна система за управление на ресурси за време и пространство, езици за висок клас софтуер или използване на отворени архитектури на приложен софтуер. Програмистите не искат да бъдат заключени в конкретни решения.
  • "Reinvent the wheel" - полагайте всички усилия, за да посочите съществуващите стандарти, където е възможно, вместо да създавате нови интерфейси и протоколи.

Стратегия за прилагане
За инициативите се използват различни стратегии за управление на системата. Проектът за интегрирана мрежа TENA (Network Enhanced Telemetry - iNET) доведе до разработването на стандартен стандарт за управление на системата. Стандартът основно се основава на Протокола за прост мрежов мениджмънт (SNMP), за да предаде информацията за управлението чрез системата. Стандартът определя SNMP мениджърска информационна база (MIB) за предоставяне на речник за информация за управлението. Устройствата носят приложения, наречени агенти, които използват MIB, за да осигурят своето вътрешно състояние и да приемат контроли и конфигурация. Това решение се вписва добре в мрежови системи, изискващи основни възможности за управление на системата.

Инициативата VICTORY включва Ethernet вътрешна автомобилна мрежа като част от инфраструктурата на превозното средство; в общи линии ръководството е изпечено в архитектурата. Пътят на VICTORY към решение за управление се основава на стандарта за управление на системата iNET. Инициативата MORA, като част от VICTORY, поема по същия начин.

За сложни платформи с много вградени изчислителни модули, основата за стабилно управление на системата идва от спецификацията на Intelligent Platform Management Interface (IPMI), разработена от Intel. IPMI е набор от спецификации на компютърен интерфейс за автономна компютърна подсистема, която предоставя възможности за управление и мониторинг, независимо от CPU на хост системата, фърмуер (BIOS или UEFI) и операционна система.

IPMI определя набор от интерфейси, използвани от системните администратори за управление на компютърни системи извън обхвата и наблюдение на тяхната работа. Например, IPMI осигурява начин за управление на компютър, който може да бъде изключен или по друг начин да не реагира, като използва мрежова връзка с хардуера, а не с операционна система или с корпус за вход. От тази широко прилагана фондация на IPMI други организации по стандартизация са изградили стандарти, специфични за обслужваните от тях индустрии.

От своя страна, PICMG разработи стандарта за управление на хардуерната платформа PICMG 3.0, съсредоточен основно върху телекомуникационната индустрия. Тя е основана на IPMI 1.5 и е доказала оперативната съвместимост и значимо полево тестване.

Стандартът VPX се извиква в няколко инициативи на OSA. Членовете на VITA разработиха стандарта ANSI / VITA 46.11 "Система за управление на системите за VPX системи", който използва PICMG 3.0, но има съображения за платформите на отбранителната система. Прекомерно сложни или ненужни функции от PICMG 3.0 бяха отстранени, докато бяха направени следните подобрения, за да се даде възможност за по-добро разполагане на системите за отбрана. Тези подобрения включват:

  • Оптимизирана диаграма на състоянието на сменяемата единица (FRU) (машина за включване / изключване)
  • Оптимизирано откриване на FRU (по-бързо наличие на система за управление)
  • Подобрено активиране на защитните елементи (NVMRO, допълнителни битове / поведение на FRU)
  • Стандартизирани функции за управление на диагностиката (инициализация и събиране на резултати)
  • DO-178B и DO-254 (архитектура на таймерни контролери)

Сега възникват нови опасения от инициативата "Хостинг на отворени системи за хардуер (HOST)", която пита дали съществуващите стандарти са пълни и достатъчни при дефинирането на всички необходими интерфейси и протоколи. Настоящата спецификация HOST Tier 2 позволява два несъвместими подхода за управление на шасито. Комуникационните връзки извън комуникацията използват I2C шина с малка честотна лента, за ANSI / VITA 46.11, но ограниченията в скоростта и структурата на данните ограничават някои желани функции. Комуникационният канал в обхвата използва високоскоростен Ethernet, но не е добре дефиниран от HOST. В този момент управлението на шасито в обхвата и извън него е несъвместимо, съгласно спецификацията на HOST.

Работната група на HOST е запитвала потенциални потребители, системни интегратори и главни контрагенти за своите данни. Ранната обратна връзка подчертава потенциалната недостатъчност на ANSI / VITA 46.11. Повечето от загрижеността се съсредоточават върху това дали I 2 C има достатъчна честотна лента за всичко, което трябва да бъде наблюдавано.

За щастие, гъвкавостта на VPX предлага много подходящи възможности за получаване на допълнителна широчина на честотната лента. Предизвикателството за работните групи на HOST и VITA е да се постигне нулево решение, което да работи най-добре за внедрени платформи. Една от възможностите на масата е да надстроите ANSI / VITA 46.11, за да добавите приложимите функции на IPMI 2.0, които адресират някои от липсващите възможности. Подобряват се управлението на фърмуера, управлението на диагностиката и сигурността.

Развиващи се решения
Фамилията от стандарти на VPX продължава да добавя възможности, които са повлияни от потребителската общност, особено от потребителите на миля / аеро. Продуктите за доставка от компании като Abaco Systems, Curtiss-Wright Defense Solutions, Elma Electronics и Mercury Systems включват поддръжка за управление на системата ANSI / VITA 46.11. Те осигуряват базови платформи и индивидуални процесори и I / O модули до пълна готовност за интегриране в платформа за отбрана.

В много случаи ще се използват модули от няколко от тези доставчици, така че нивото на поддръжка на системния мениджмънт става критично. Базовата платформа OpenVPX на Elma Electronics ( фиг.1 ) включва интерфейси за управление на системата. Също така, няколко членове на бордовите продукти Mercury Systems Ensemble 3000 и Ensemble 6000 OpenVPX включват бордови IPMI контролери ( фиг.2 ).

Фигура 1: Базовите платформи OpenVPX на Elma Electronics включват интерфейс за управление на системата съгласно VITA 46.11. Източник на изображението: Elma Electronics.

Фигура 2: Няколко членове на бордовите продукти Ensemble 3000 и Ensemble 6000 OpenVPX на Mercury Systems включват бордови IPMI контролери.