¬аше окно в мир —јѕ–
 
Ќовости —татьи јвторы —обыти€ ¬акансии Ёнциклопеди€ –екламодател€м
—татьи

13 июн€ 2012

—јѕ– средств контрол€ и мониторинга систем управлени€ самолЄтом

»ль€ ¬ерещагин

ќт редакции isicad.ru: ћногие из нас часто совершают перелЄты на самолЄтах, некоторые осознают, что компьютеры очень активно примен€ютс€ не только при конструировании этих больших железных птиц, но и помогают пилотам в каждом полЄте. ј совсем единицы имеют представление, каким образом происходит написание программ дл€ компьютеров, которым доверены жизни пассажиров на борту. —егодн€ мы пригласили »лью ¬ерещагина (сотрудника компании Auriga, работавшего над проектами Airbus, Bombardier, Sukhoi) поделитьс€ с нами некоторыми подробност€ми чрезвычайно ответственных процессов проектировани€, разработки и тестировани€ ѕќ авионики.

¬ основе разработки ѕќ авионики лежит основополагающий стандарт RTCA\DO-178B. Ќа первый взгл€д, несмотр€ на его отстранЄнность от непосредственной рутины программиста, он описывает весь процесс разработки и выдвигает требовани€ к подобному ѕќ. “ем не менее, в данной статье речь пойдЄт и о том, как всЄ происходит на самом деле, на основе личного опыта разработки систем контрол€ и управлени€ полЄтом, систем посадки и пр. дл€ самолЄтов и вертолЄтов.

¬ступление

—овременные решени€ дл€ контрол€ и мониторинга систем управлени€ самолЄтом (Flight Control System) — сложный программно-аппаратный комплекс, работу которого, пожалуй, в целом не знает ни один из сотрудников и разработчиков. Ёто сродни проектам разработки атомной бомбы времЄн второй мировой войны, где каждый хорошо знает часть своей работы, но не особо представл€ет, почему это работает вместе. ¬прочем, авионика не единственный пример таких сложных систем, и сложность тех же Microsoft Excel или GNU GCC, конечно, порождает схожие проблемы, но, тем не менее, дл€ ѕќ авиации существуют нюансы и типичные решени€, на которых € постараюсь отдельно остановить своЄ внимание. —то€ перед проблемой эффективности управлени€ процессом разработки, менеджмент, стара€сь следовать оптимизации параметров затрат и качества проекта, порождает информационный и организационный дефицит. Ёто св€зано, в первую очередь, с высокой стоимостью специалистов и/или их обучением в области авиационного ѕќ, т.е. с персоналом, т.к. зачастую в крупных проектах его численность может достигать пор€дка 2-3 тыс€ч человек на одну только систему управлени€ (не говор€ о динамической модели и физическом исполнении планера, а тем более всего издели€). ¬о вторую очередь — с организацией св€зи и подачей информации, еЄ синхронизацией между участниками разработки, а так же ограничени€ми на чрезмерно большие количества данных, проход€щих через тот или иной уровень. ѕоэтому дл€ разработки подобных систем утверждЄн особый, тщательно задокументированный и регламентированный технический процесс разработки требований, создани€ аппаратной и программной части, выполнени€ и отладки системы, а так же еЄ тестировани€ и составлени€ сертификационной документации. “ем не менее, процесс посто€нно модифицируетс€ и совершенствуетс€, исход€ из реалий проекта и из картины окружающего мира.

ћодель разработки

ƒл€ разработки критически важных систем необходимо обеспечить минимальную возможность ошибки (дл€ самого высокого уровн€ в авионике установлена веро€тность отказа 10^-9), а так же минимизировать расходы на разработку и исправлени€ кода. »з-за сложности системы и взаимосв€зи с другими част€ми (другим ѕќ, другой аппаратурой), модель водопада или гибкой разработки может быть не лучшим вариантом, поэтому, основополагающим принципом разработки подобного ѕќ выбрана V-образна€ модель разработки.

–ис 1. V-образна€ модель разработки.

¬ первую очередь, така€ модель позвол€ет обеспечить синхронизацию всех участников проекта на каждой итерации, а так же предоставл€ет возможность использовать уже наработанные данные и готовую методологию, т.к. на старте любого проекта V-образна€ модель (рис 1.) может быть адаптирована под этот проект, так как эта модель не зависит от типов организаций и проектов. V-model позвол€ет разбить де€тельность на отдельные шаги, каждый из которых будет включать в себ€ необходимые дл€ него действи€, инструкции к ним, рекомендации и подробное объ€снение де€тельности. Ёто особенно важно дл€ многоитерационного цикла разработки и тестировани€ ѕќ авионики, т.к. позвол€ет, фактически, разбить непосредственно разработку ѕќ на отдельные подциклы. ќбычно V-model обобщаетс€ в спиральную модель разработки (рис 2).  отора€, в свою очередь, уже позвол€ет оценить риски на каждом этапе разработки, а так же оптимально распредел€ет зан€тость специалистов (workload) в услови€х дефицита сотрудников и времени на короткие промежутки времени (Iteration Packages, синхронизирующиес€ с V-образной моделью в каждый Baseline).

–ис 2. —пиральна€ модель разработки-тестировани€ ѕќ

ѕроектирование и документаци€

ƒл€ контрол€ каждого этапа и дл€ последующей возможности сертификации процесс разбит на различные уровни, каждому из которых соответствует свой документ, дл€ которого создаЄтс€ в последствие документ, контролирующий его (отчЄт). ¬ итоге каждый этап разработки, все ошибки и исправлени€ классифицируютс€ и документируютс€. ѕовтор€€ каждый раз итерации разработки веро€тность ошибки снижаетс€. ƒанные документы так же создаютс€ на основе внутренних стандартов компании и требований, предъ€вленных заказчиком.

–ис 3. ¬заимосв€зь документов и требований

¬о главе всего стоит, естественно, заказчик, который зачастую не особо представл€ет, что ему надо, но вполне способен сказать, что он хочет, чтобы его самолЄт летал, имел систему рулЄжки и кондиционировани€ на все случаи жизни, а так же чтобы это система работала так, как он этого хочет, и ещЄ даже с бонусами. ѕоэтому перва€ часть — это анализ требований заказчика и определение базовой функциональности системы, на основе которой создаЄтс€ обща€ концепци€ и схема системы, включа€ технические подробности используемого оборудовани€, т.е. создани€ первоначальных спецификаций системы (Equipment Specification) и требований (System Requirements).

 огда определена база на которой будет создаватьс€ система, утверждаетс€ план, по которому будет проходить разработка ѕќ (Software Development Plan) и его сертификаци€ (Qualification Plan — plan for Software Aspects of Certification). Ќесмотр€ на то, что главное дл€ заказчика получить готовое ѕќ управлени€, параллельным процессом €вл€етс€ разработка аппаратной части, которую в разработке ѕќ нельз€ обойти стороной, т.к. разработка ѕќ авионики очень тесно св€зана с аппаратной частью; в большинстве своЄм ѕќ €вл€етс€ хоть и переносимым и встраиваемым кодом, но сильно зависимым от компоновки систем, но об этом чуть позже.

–ис 4. V-образна€ модель, разбита€ на этапы согласно уставным документам

–азработка

 онцепци€
ѕрежде, чем переходить дальше, стоит сказать, что в основе первоначального проектировани€ лежат основополагающие принципы, которые присутствуют во всем процессе разработки, и главный из них — это «различие» (dissimilarity), которое определ€ет то, что кажда€ часть из систем управлени€ должна быть реализована разными группами людей на разной аппаратной начинке с использованием разных программных средств (в том числе средств разработки, €зыков программировани€). “аким образом, система раздел€етс€ на программно- и аппаратно- независимые части, а процесс разработки контролируетс€ разными группами людей дл€ разных задач и на разных уровн€х соответственно сообразно вышесто€щим требовани€м и плану.
ѕрограммно-аппаратна€ часть
–езультатом первичного проектировани€ €вл€етс€ модель системы, обычно выполненна€ в средах Matlab/Simulink, Labview. Ќа основе модели создаютс€ документы, регламентирующие, какие аппаратные средства должны быть использованы и какие св€зи они должны иметь между собой.  ак минимум результатом этого этапа €вл€етс€ создание двух документов: определ€ющих аппаратную компоненту (hardware) и программно-аппаратную (hardware-software).

ƒалее начинаетс€ этап инженерного процесса подготовки, сборки плат и готовых модулей (Control Electronic и т.п.), т.е. непосредственно монтаж, разводка необходимых микроконтроллеров, микросхем, периферии, дл€ которых будет написано необходимое ѕќ. ƒл€ взаимодействи€ с аппаратной частью должны существовать драйверы и слой взаимодействи€ (framework layer), на основе которых должно быть построено приложение (application). “ем не менее, зачастую работа программиста начинаетс€ уже здесь, когда необходимо дописать необходимые драйверы/функциональность, а чаще всего внести изменени€ во «всеобъемлющую библиотеку», на основе документа HSI (Hardware-Software Interface). “ак, наиболее частой практикой €вл€етс€ «урезание» функциональности системы до предела используемой аппаратуры и драйверов, а так же изменение некоторых калибровочных настроек, включа€ необычную распиновку или оптимизацию под выбранные параметры реального времени.

–ис 5. ќрганизаци€ ѕќ

Framework
—оответственно, универсальна€ библиотека Framework включает в себ€ всевозможные драйверы дл€ устройств, сертифицированных дл€ использовани€ в авиации, а так же сертифицированных стандартных функций и процедур.

Ёто принципиальный момент, потому что сама€ обычна€ функци€ strcmp, допустим, не может быть использована напр€мую, она должна быть переписана сообразно стандартам и пройти сертификацию. Ќабор таких сертифицированных стандартных функций, прототипов, шаблонов и есть Common в слое Framework. ќсобенно критично такое отношение к безопасным математическим операци€м (быстрое дробное деление дл€ целочисленных процессоров, модуль, корень, как пример), так и дл€ работы с пам€тью. ¬се алгоритмы хоть и немного (как минимум стилем кода), но отличаютс€ от STL.

–ис 6. јрхитектура тестового кластера, с возможностью использовать различные интерфейсы контрол€ и анализа*

ƒл€ использовани€ на всевозможных устройствах в состав Framework вход€т наборы драйверов, име€ структуру DrvHigh<->DrvLow. «десь, в пакете DrvHigh содержатс€ всевозможные интерфейсы дл€ драйверов устройств (Flash, Eeprom пам€ть, цифро-аналоговые, аналого-цифровые преобразователи, часы реального времени, прерывани€, чипы CAN, ARINC, LAN и т.п.). ¬ свою очередь, каждый из этих интерфейсов драйверов может использовать один или несколько драйверов под конкретное устройство (ту или иную микросхему пам€ти, конвертера и т.п.). ¬ цел€х оптимизации подобные драйвера переконфигурирютс€ или даже используютс€ напр€мую без уровн€ DrvHigh. Ѕыть может, это не самое красивое решение, но в отличие от прикладных программ, работа со встроенными системами жесткого реального времени, где «640кб должно хватить всем» — не просто афоризм, а реалии. ƒл€ высоконагруженных и отказоустойчивых систем реали€ми €вл€ютс€ как пиковые загрузки микросхем, 90-100% загруженность шин передачи данных, синхронизаци€ каналов, устройств и планирование загрузки фрейма в зависимости от входных параметров (frame scheduling) с контролем ошибок (в т.ч. разноуровневым мониторингом с подтверждением статичных и осцилл€ционных ошибок), так и укладывание всего ѕќ и объектов данных в объемы пор€дка 64-128кбайт.

ѕрограммирование

“ребовани€

Ќо вернЄмс€ к циклу разработки ѕќ.  ак только установлена и сконфигурирована аппаратна€ часть, создаЄтс€ документ требований к ѕќ (Software Requirement Document), который описывает то, что должно ѕќ делать, а так же как это делать. Ёто тот документ, на основе которого должно быть разработано ѕќ (application). “ут и начинаетс€, собственно, работа программиста вкупе с работой тестировщика. »так, другими словами, программист ѕќ авионики не видит полной картины того, дл€ чего он создаЄт программу на самом деле, но оперирует необходимыми требовани€ми и архитектурой, которую он должен создать на основе требований. “ребовани€ми дл€ программиста €вл€ютс€ следующие документы:

  • Software Design Standard — стандарт, определ€ющий общий стиль приложени€ и подход к созданию архитектуры.
  • Programming Standard — стандарт программировани€, определ€ющий, что разрешено писать в коде и каким стилем.
  • Software Requirements Document — требовани€ к ѕќ, задокументированные и разделЄнные на различные Baseline и iteration package внутри них (high-level specificaction).

Ќа основе первого документа разработчику устанавливаетс€ способ решени€ его задачи: какие технические средства он может использовать, какие и куда он должен заносить результаты, а так же каких правил (rules) и советов (guidelines) он должен придерживатьс€. ≈сли говорить совсем просто, то этот документ устанавливает инструментарий разработчика (€зык программировани€, среду разработки и отчЄтов).

Ќа основе второго документа разработчику устанавливаетс€ стиль его кода и разрешЄнные приЄмы. Ќапример, использование венгерской нотации, арифметических операций, стилистики написани€ кода и его сложности.

“ак же дл€ работы разработчика, как € уже упоминал, могут потребоватьс€ знани€ низкоуровневых требований (HSI, ICD (Interface Communication), Datasheets (документов, описывающих работу устройств, как правило от создателей устройств (на различные чипы)).

ѕроцесс

Ќепосредственно сам процесс разработки состоит из следующих этапов:

  1. Design — дизайн (разработка дизайна в UML и/или системе моделировани€ (использу€ такое ѕќ как Ameos, SCADE, Simulink и т.п.) —
  2. Low-Level Requirements — ќписание функциональности и алгоритма решени€ реализуемого требовани€ дл€ тестировщика (использу€ модель чЄрного €щика: описание входа и ожидаемой реакции). “.е. низкоуровнева€ спецификаци€.
  3. Coding — процесс непосредственного написани€ кода (в чЄм угодно, если не используетс€ автоматический кодогенератор, как в SCADE/Matlab, т.к. среда разработки (IDE) может быть любой и может быть испльзована под любой ќ— (€ использую Eclipse, CodeBlocks, хот€ и другие решени€ не возбран€ютс€).
  4. Debugging — процесс отладки, а точнее процесс переработки и сборки до состо€ни€ отсутстви€ ошибок (отсутстви€ Errors, Warnings с установленными параметрами выбранного компил€тора).
  5. Static check — процесс проверки и исправлени€ кода на основе анализаторов кода (xLite, Polyspace, MISRA, QAC).
  6. Engineering tests — процесс запуска и интеграции ѕќ на симул€торе (т.е. на прототипе оборудовани€, финальный вариант которого в последствие будет установлен в полЄт, с выведенными по возможности интерфейсами и инструментами манипул€ции (обычно это св€зка Labview + Trace32 debugger)). ¬ некоторых случа€х функциональность симул€тора расшир€етс€ путЄм установки дополнительных устройств (датчиков, цепей разрыва, генераторов сигнала и даже приборов управлени€ и контрол€, таких как ручка пилота и т.п.). ¬ особо редких случа€х дл€ немногих систем управлени€ это можно проделать на насто€щей полномасштабной стендовой модели самолЄта.
  7. ¬несение результатов в систему контрол€ версий и отчЄтов (IBM Rational ClearCase/ClearQuest).

–ис 7. «Ёлектронна€ птица» Sukhoi SuperJet 100*

¬се эти семь пунктов составл€ют одну итерацию, как правило выполн€ющуюс€ только дл€ своей части требований. »з-за изменени€ функционала или внесени€ исправлений/поправок в уже протестированный код необходимо составление Change Request’ов, на основе которых, как документа, будут внесены корректировки в существующую отчЄтную документацию или код, обычно это происходит в системе. ѕо закрытии одного из Baseline, последующие изменени€ в код или документацию не внос€тс€, а лишь могут быть инициированы на основе Problem Report’ов. “ака€ сложность нужна, чтобы избежать несанкционированного и опасного изменени€ кода и документации, и стабилизировать код так, как есть до соответствующей активности. —амо же изменение кода и/или спецификации после разрешени€ на Change Request, где документируетс€, какие именно правки были внесены.

—пецификаци€

ѕо завершении каждого из Baseline проводитс€ формирование документа SDD (Software Description Document), в котором содержитс€ информаци€ о дизайне приложени€, а так же низкоуровневых требований, предоставленных разработчиком тестировщику. ќднако, прежде чем передать его тестировщикам, производитс€ анализ и ревью (design review) этого документа на наличие ошибок и возможности тестировани€ на приведЄнных в документе требований (производитс€ другим разработчиком, обычно отвечающим за другую часть функциональности). Ќа этом работа разработчика заканчиваетс€, и он переходит либо к следующему Baseline или, если проект закончен, к следующему проекту. ѕри этом, естественно, разработчик вступает в качестве консультанта в св€зь с тестировщиком, оказыва€ ему необходимое содействие.

“ем не менее, необходимо упом€нуть, что каждое из звеньев (системный инженер, программист, тестировщик) должно быть разделено во избежание возможного вли€ни€ и давлени€ с их стороны. Ќо, конечно же, всегда есть спорные вопросы и нюансы, и иногда, несмотр€ на чЄткость процесса, чтобы не загромождать техпроцесс итераци€ми из-за опечаток в комментари€х (например), зачастую примен€етс€ модель agile-разработки, не затрагивающей главный функционал.

“естирование

–абота же тестировщика — это почти половина, если не 2/3 всего времени разработки ѕќ. Ёто кропотливый и длительный труд, который включает в себ€:

Ќизкоуровневое тестирование

которое состоит, в свою очередь, из:

  • Code review — ревью исходного кода на предмет соответстви€ стандарту программировани€, а так же на предмет соответстви€ кода и требований (SDD).
  • Low-Level Testing — низкоуровневое тестирование, такое, как unit-testing и unit-integration-testing (Razorcat Tessy + эмул€торы среды и процессоров), т.е. тестирование на основе требований непосредственно кода, использу€ метрику ћаккейба и Modified Condition/Decision Coverage (использу€ стандарт NASA MCDC). “ак же тут провер€ютс€ все граничные значени€, а так же реакци€ системы на выход из допустимых условий (реакци€ на недопустимые математические операции, на операции с пам€тью, указател€ми, выход за пределы диапазона и пр. (robustness testing)).
  • —оздани€ документа отчЄтности (Software Verification Cases and Procedures / Software Unit and Integration Verification Cases and Procedures).
  • VoV (Verification of Verification) — процесс проверки проверки, на которой провер€етс€ правильность выполнени€ тестов а так же созданного документа, с занесением результатов в QAR (Quality Assurance Record), которое в последствии будет использоватьс€ на следующей итерации дл€ исправлени€ возникших ошибок (выполн€етс€ другим тестировщиком). ≈стественно, все ошибки фиксируютс€ помимо QAR и в багтрекинговой системе, чтобы по Iteration можно было найти и исправить проблему.

¬ последующих итераци€х процесс может быть минимизирован до delta-тестировани€ и delta-ревью, т.е. “естировани€ только изменившихс€ частей программы/документа или исправлени€ предыдущих ошибок тестировани€. Ёто должно экономить врем€, однако, зачастую, как показывает практика, ошибки присутствуют и до конца всего процесса разработки, поэтому нередко тестировщики тестируют систему полностью каждый раз на основе готовых тестов. Ёто можно рассматривать как регрессионное тестирование, за исключением высоких временных затрат и зачастую повышенного процента изменений в коде/тестах. «десь, подчеркну, что это происходит из-за того, что тесты создаютс€ на основе системы, а не параллельно с ней.  ак можно догадатьс€, из-за такого подхода, главные проблемы ложатс€ на плечи программистов, которые должны выдать превосходный баланс из архитектуры, кода и низкоуровневой спецификации. ѕараллельна€ же разработка почти невозможна из-за необходимости иметь возможность проследить ошибку вплоть до функции и переменной, вызывающей сбой. Ќе только в тестах, но и на уровне требований. ’от€, это выгл€дит как т€желый минус, от такой модели постепенно стараютс€ перейти к более гибким модел€м, и сделать процесс black-box, чтобы тесты исходили не от кода, а шли от этапа проектировани€ архитектуры. ¬ идеале составл€ть спецификации до написани€ кода.

–ис 8. »спытательные стенды электроники и сопутствующих систем*

¬ысокоуровневое тестирование
  • Document review (SWRD review) — ревью документа на предмет наличи€ ошибок и тестируемости с точки зрени€ требований и спецификации к системе, а так же Hardware-Software соответствий (ICD, HSI).
  • Hardware-Software testing — процесс создани€ и запуска высокоуровневых тестов на симул€торе, которые могут быть автоматическими (скриптовыми), ручными (скриптовыми, с необходимостью где-то что-то аппаратно переключить, померить мультиметром или осциллографом), Unit-тестами (в случае, когда нельз€ проверить на симул€торе, изымаетс€ тест/тесты из низкоуровневых). “акое тестирование очень близко к Engineering тестам, которые проводит разработчик, за исключением того, что их результаты занос€тс€ в файл отчЄта (Hardware/Software Integration Verification Cases and Procedures), а весь процесс, как правило, автоматизирован.
  • HwSw VoV — процесс проверки проверки, на которой провер€етс€ правильность выполнени€ тестов а так же созданного документа, с занесением результатов в QAR (Quality Assurance Record), которое в последствии будет использоватьс€ на следующей итерации дл€ исправлени€ возникших ошибок (выполн€етс€ другим тестировщиком).

„уть реже, на заключающих этапах разработки встречаетс€ чисто аппаратное тестирование, которое подразумевает собой тестирование на реальном оборудовании с составлением акта. ќбычно это происходит на стендовых испытани€х собранной модели самолЄта, а в последствие в полЄте на реальном самолЄте.

ћежду каждым этапом, естественно, формируетс€ «пакет поставки», включающий в себ€ как спецификацию использованного оборудовани€, версии всех устройств и документов, так и само ѕќ и сопутствующие документы. Ётим занимаютс€ специализированные менеджеры (package manager), а координацией и отслеживанием состо€ни€ различных групп занимаютс€ координаторы (coordinator manager). —ами же этапы разработки и тестировани€ регламентируютс€ внутренними планами (roadmap), которые так же €вл€ютс€ отчЄтным документом дл€ менеджеров (actual status).

—ертификаци€

Ќа основе тестов составл€етс€ общий документ SVR (Software Verification Review), который на том или ином этапе разработки определ€ет состо€ние ошибок. Ќа основе которого, в зависимости от их важности, составл€етс€ документ об окончании этапа (SAS, Software Accomplishment Summary). Ётот документ определ€ет, необходим ли старт нового этапа разработки/переработки (включа€ переработку SWRD), либо разработка прекращаетс€, и вс€ документаци€ передаЄтс€ на сертификацию и заказчику. Ётот документ €вл€етс€ финальным дл€ отдела технического контрол€, работа которого проводитс€ посто€нно дл€ каждого Baseline в фоне, обычно не име€ сильного вли€ни€ на техпроцесс.

Ќа этом моменте начинаетс€ аудит и проверка всего проекта, на основе которого создаютс€ последние три документа:

  • First Delivery Review (FDR) — документ о поставке пакета,
  • First Flight Review (FFR) — отчЄт о первом полЄте,
  • Software Certification Review (SCR) — решение сертификационной комиссии.

≈стественно, если на одном из этих этапов возникнут проблемы, вполне возможна ситуаци€ дл€ инициации ещЄ одной (как минимум) переработки ѕќ.  ак правило, така€ сертификаци€ из-за обили€ документации (это пор€дка 100-200 тыс€ч страниц) провер€етс€ исключительно выборочно на низком уровне, а на высоком по ответам заказчика, сертификационной комиссии и лЄтчиков-испытателей составл€етс€ требовани€ на доработки.  ак правило, количество этапов лЄтной проверки равно двум-трЄм, а сертификационной — 1-2.

«аключение

„то же касаетс€ гигантских объемов работ, врем€, отведЄнное на разработку относительно простой системы (система рулЄжки и выпуска шасси) — 1,5-2 года, дл€ систем управлени€ поверхност€ми (электрическими актуаторами и гидросистемами) составл€ет 5-6 лет. “аким образом, в среднем система проходит от 2-3 больших итераций (baseline) до 18-20 дл€ больших и сложных систем, и более 40 дл€ сло€ Framework.

»з-за чрезвычайной сложности и громоздкости систем отчЄта и рутины тестировани€ дл€ работы привлекаютс€ ресурсы аутсорса в »ндии, чуть реже — в  итае, восточной ≈вропе. ¬с€ сертификаци€, как правило, проходит на территории, где действителен сертификат (дл€ EASA — ≈вропа, дл€ FAA — јмерика), ну и дл€ –оссийский стандартов — –осси€. ќборудование сертифицируетс€ отдельно, либо уже должно иметь свой сертификат, поэтому, к сожалению, или к счастью, в авиации используютс€ относительно «устаревшие» модели и решени€, проверенные в температурных, временных и агрессивных услови€х эксплуатации. Ќесмотр€ на огромную сложность и востребованность, хороших специалистов не так уж и много, и даже в јмерике и ≈вропе — электронные системы управлени€ — только начинающеес€ направление, которое, конечно, содержит хоть и небольшую, но порцию ошибок... впрочем, чтобы не пугать, о безопасности и отказоустойчивой архитектуре речь пойдЄт в следующий раз.


* “естова€ система подготовлена в сотрудничестве с Cosateq.

ƒобавить комментарий

„итайте также:


¬акансии:

јктуальное обсуждение

RSS-лента комментариев

ƒавид Ћевин
ƒавид Ћевин
ќт редактора: „то такое +20%: Ёффект внедрени€ BIM? –ост выручки ƒассо?...
ѕроект ЂЌародное —јѕ–-интервьюї

—лучайна€ стать€:

isicad Top 10

—амые попул€рные материалы

   ‘орумы isicad:

isicad-2010 isicad-2008
isicad-2006 isicad-2004

ќ проекте

ѕриглашаем публиковать на сайте isicad.ru новости и пресс-релизы о новых решени€х и продуктах, о проводимых меропри€ти€х и другую информацию. јдрес дл€ корреспонденции - info@isicad.ru

ѕроект isicad нацелен на

  • укрепление контактов между разработчиками, поставщиками и потребител€ми промышленных решений в област€х PLM и ERP...
ѕодробнее

»нформаци€ дл€ рекламодателей


¬се права защищены. © 2004-2019 √руппа компаний «Ћ≈ƒј—»

ѕерепечатка материалов сайта допускаетс€ с согласи€ редакции, ссылка на isicad.ru об€зательна.
¬ы можете обратитьс€ к нам по адресу info@isicad.ru.