Русский
Русский
English
Статистика
Реклама

Асутп

Assurance Case аргументированное обоснование безопасности

02.11.2020 06:06:01 | Автор: admin

source

Как наиболее полно оценить безопасность, и ничего при этом не упустить? Возможно ли собрать в одном документе (или диаграмме) все разнообразие артефактов, относящихся к безопасности, и организовать их таким образом, чтобы можно было наглядно представить любой аспект с понятным уровнем детализации?

Технические специалисты были бы рады изобретению такого философского камня, который, если даже не обеспечил бы безопасность, то, по крайней мере, оценил бы ее с требуемым уровнем полноты. Подобные наработки существуют уже более 20 лет, однако, практически не известны русскоязычному читателю. Речь пойдет о методологии Assurance Case (или Safety Case), под которой подразумевается структурированный набор аргументов и документальных подтверждений, обосновывающих соответствие системы или сервиса заданным требованиям.

Введение


Перед прочтением статьи хотел бы обратить ваше внимание на пару важных моментов. Изложенный материал применим, в первую очередь, для объектов критической информационной инфраструктуры (КИИ). Для таких объектов, в частности, для информационных и управляющих систем, должен быть выполнен анализ безопасности. Результаты анализа безопасности представляются в виде соответствующих отчетов. Все это выполняется уже десятки лет, однако, отчеты, как правило, имеют произвольную текстовую форму, в логике которой не всегда просто разобраться.

Основная идея излагаемого подхода состоит в том, что результаты анализа безопасности могут быть представлены в графическом виде с использованием полуформальных нотаций, со всеми вытекающими отсюда преимуществами. Таким образом, Assurance Case является способом интегрального представления всех мер по обеспечению и оцениванию безопасности, не заменяя и не отменяя такие частные методы, как, например, тестирование, статический анализ кода, расчет надежности, FMEA, анализ рисков и т.п. Данная статья продолжает ранее опубликованную серию статей по безопасности.

Карты аргументов и их философские истоки


Как мы можем понять или утверждать, что некоторый объект является безопасным? Очевидно, для этого надо ввести ряд критериев. Однако, для этих критериев нам необходимо определить, насколько наше знание об объекте является достоверным? Почему мы можем этому знанию доверять? Что делает наши доводы и рассуждения действительно заслуживающими доверия? Углубившись в подобные проблемы, нельзя обойтись без философских дисциплин, таких как, онтология, гносеология, эпистемология, логика, а также, без великих мыслителей, которых волновали эти вопросы. В античном мире таковыми являлись Аристотель и Платон, а в эпоху нового времени основоположником современного научного метода считается Френсис Бэкон.

Что же можно сделать для обоснования или оценки безопасности разумным и логичным путем? В основе такого подхода лежит теория аргументации. Новый импульс современному развитию аргументации был дан в работе британского философа Стивена Тулмина под названием The Uses of Argument, изданной в 1958 году. Тулмин расширил логический импликативный вывод дополнительными параметрами и предложил представлять эту операцию в графической форме. Нотация Тулмина оперирует следующими сущностями: data (D) исходные данные для анализа, claim (С) цель логического импликационного вывода (If D So C), warrant (W) дополнительный аргумент, qualifier (Q) степень уверенности в результатах логического вывода, rebuttable (R ) дополнительный контраргумент (Рисунок 1).


Рисунок 1. Нотация Стивена Тулмина

Карты аргументов или аргументации (Argument Map) использовались в целях визуализации рассуждений и до Тулмина, но именно он наиболее удачно обобщил структурную модель для анализа и верификации аргументов. Отметим, что в современных картах аргументов, как правило, не используется нотация Тулмина, все упрощено, например, как на рисунке ниже. Это нотация, используемая платным онлайн сервисом Rational (бесплатная версия существует, но она крайне ограничена по функционалу) (Рисунок 2). Платная версия умеет преобразовывать полученные диаграммы в логически структурированный текст. На сайте также доступны бесплатные guides & tutorials по критическому мышлению и составлению карт аргументов.


Рисунок 2. Карта аргументов, разработанная при помощи сервиса Rational

Как видим, все довольно прозрачно, существуют всего четыре сущности и три типа связи между ними. Результат логического ввода называется Contention, подтверждающий аргумент Reason (связь because), контраргумент Objection (связь but), а вот контраргумент для контраргумента имеет специальное название Rebuttal (связь however).

На данный момент не существует общепринятой нотации для составления карт аргументов. Нет единства и в обозначениях, применяемых для структуры аргументов. Например, результат логического вывода может называться claim, contention, conclusion, goal. Аргументы могут называться premise, justification и т.д. В области моделирования аргументов существует ряд международных инициатив и сообществ (например, Argument Interchange Format, AIF), но вопросы унификации они не решили. Существуют исследования, проводящие параллели между картами аргументов и ментальными картами (Mind Map, наверно, все о них слышали). Действительно, возможности Mind Map редакторов позволяют построить аналог карты аргументов.

История и концепция Assurance Case


Какое отношение имеет все это к безопасности? Чтобы ответить на этот вопрос, обратимся ко второй половине ХХ века, именно там берет свое начало современная теория и практика обеспечения безопасности. Тогда, в результате развития сложных техногенных отраслей, таких, как атомная энергетика, космическая техника, нефтегазовая и химическая промышленность, транспорт, человечество столкнулось с техногенными катастрофами невиданных ранее масштабов.

Тогда и появилась первые отчеты по анализу безопасности, в которых сводились воедино вся релевантные требования, а, также, информация, подтверждающая их соблюдение. Позже появился термин Safety Case (по сути, аналитический отчет по безопасности), который являлся предшественником Assurance Case. Отметим, что термины Safety Case или Assurance Case напрямую перевести термин на русский язык невозможно, в данном контексте, наиболее логичным переводом является обоснование безопасности. Хотя, например, в российских переводах серии стандартов ИСО/МЭК 15026 (Systems and software engineering Systems and software assurance) Assurance Case переведен, как гарантийный случай.

Следует отметить, что в некоторых отраслях термин Safety Case применяется и в настоящий момент, наравне с Assurance Case. Assurance Case, будучи более современным термином, противопоставляется Safety Case в том смысле, что на сегодняшний день система должна соответствовать не только требованиям safety (функциональная безопасность), но, также, и security (информационная безопасность). Поэтому, предлагается использовать понятие Assurance Case, а Safety Case считать его частным случаем.

Под Assurance Case, в современном понимании этого термина, подразумевается отчет о выполненном анализе безопасности, включающий визуальное представление в виде графа или таблицы, полученных с применением полуформальных нотаций (о нотациях речь пойдет ниже). При этом, получается некоторое разночтение одного и того же термина, поскольку возможно трактовать Assurance Case, с одной стороны, как некоторый документ (отчет об анализе безопасности или отчет об обосновании безопасности), а, с другой стороны, как систему аргументации с использованием полуформальной нотации. В идеале, Assurance Case, может включать оба компонента, то есть документ, оценивающий безопасность, строится на основании модели аргументов.

Вернемся, однако, в ХХ век. Первым нормативным документом, требующим разрабатывать и анализировать Safety Case для потенциально опасных индустриальных объектов, стал CIMAH (Control of Industrial Major Accidents Hazards) Regulations, первоначально выпущенный в Великобритании в 1984 году, а затем адаптированный и в ряде других стран. Более широкое внедрение Safety Case в практику стало происходить после небывалой аварии на нефтяной платформе Piper Alpha в Северном море, унесшей в 1988 году жизни 167 человек.

В 1990-х годах исследователи продолжают искать новые подходы к оцениванию безопасности. Идея, вроде бы, лежит на поверхности: давайте разработаем специальную нотацию для обоснования соответствия техногенных объектов и систем требованиям по безопасности. За дело взялись две британские университетские команды, лондонский университет Сити (City, University of London), где была создана спин-офф компания Adelard, и университет Йорка (University of York). Надо сказать, что и в наши дни Adelard и университет Йорка занимают лидирующие позиции в области продвижения Assurance Case.

Для разработки нотаций упор был сделан на логическую аргументацию того, что свойство или компонент системы соответствует заявленным требованиям. В качестве теоретической основы были выбраны уже рассмотренные нами труды Стивена Тулмина. Будучи гуманитарием, Тулмин вряд ли он думал о техногенных системах, однако, в историю, он вошел, в том числе, и как основоположник аргументации для Assurance Case.

Взяв за основу, нотацию Тулмина, британцы вскоре разработали методологию Assurance Case (называемую в то время Safety Case) и довели результаты до практических индустриальных внедрений. В университете Йорка, была разработана Goal Structuring Notation (GSN), эту тему продвигал PhD студент Tim Kelly под руководством профессора John McDermid. В результате произошел тот редкий случай, когда диссертация Arguing Safety: A Systematic Approach to Managing Safety Cases. PhD thesis. University of York, 1998 уже больше 20 лет считается классическим трудом, и ее продолжают активно цитировать. Однако, подход к решению проблемы безопасности был, на мой взгляд, в большей степени академический, и, как результат, не был почему-то сделан вроде бы понятный и логичный шаг, связанный с разработкой программного средства для поддержки Assurance Case.

Adelard же, под руководством Robin Bloomfield и Peter Bishop, напротив, в первую очередь стремился к коммерциализации результатов. Параллельно с Йорком, в Лондоне была разработала нотация Claim, Argument and Evidence (CAE), а также программный инструмент Adelard ASCE (Assurance and Safety Case Environment), который поддерживает и CAE, и GSN. В Великобритании разработка Assurance Case (Safety Case) требуется законами и стандартами во многих областях, связанных с безопасностью, поэтому ASCE имеет здесь довольно устойчивый рынок. ASCE был и остается наиболее используемым инструментом разработки Assurance Case. Основной частью инструмента является графический редактор, в котором к графическим блокам может быть прикреплена дополнительная текстовая или гиперссылочная информация (Рисунок 3). Самостоятельно загрузить программное обеспечение ASCE с веб-сайта Adelard не получится. Вы должны заполнить запрос на 30-дневную пробную версию или академическую лицензию, после чего запрос будет рассмотрен компанией.


Рисунок 3. Интерфейс программы Adelard ASCE

Теперь рассмотрим две базовые нотации, применяемые для разработки Assurance Case (CAE и GSN).

Нотация CAE (Claim, Argument and Evidence)


Нотация CAE (Claim, Argument and Evidence цель, аргумент, подтверждение) оперирует тремя указанными сущностями: цели указывают на достижение требуемых свойств системы, подтверждения предоставляют документированный базис для аргументации, демонстрирующей достижение либо не достижение целей, аргументы строятся при помощи правил вывода и связывают подтверждения с целями. Обычно применяются такие аргументы, как детерминистские (или логические), вероятностные и качественные. Для обозначения целей, аргументов и доказательств вводятся графические примитивы, имеющие различную форму (Рисунок 4).

Рисунок4. Нотация Claim, Argument and Evidence (CAE): основные компоненты

Построение иерархии целей и подцелей является первым этапом разработки Assurance Case. Как показано на схеме, структура целей, аргументов и подтверждений не обязательно является трехуровневой, например, для поддержки аргументации могут использоваться дополнительные подцели. CAE нотация также легко трансформируется в табличный вид. Столбцами такой таблицы будут являться все те же цели, аргументы и подтверждения, между которыми теперь будут установлены связи в пределах табличных записей. Подобный подход к разработке Assurance Case используется, например, компанией exida.

Нотация GSN (Goal Structuring Notation)


GSN оперирует такими компонентами, как цель (goal, обозначается прямоугольником и является аналогом claim в CAE), стратегия аргументации (strategy, обозначается параллелограммом и является аналогом argument) и решение (solution, обозначается кругом и является аналогом evidence) (Рисунок5). Контекст (context) применяется для информационной поддержки целей. Для поддержки аргументации могут применяться предположение (assumptions) и обоснование (justifications). Структура целей имеет иерархический характер.


Рисунок5. Нотация Goal Structuring Notation (GSN): основные компоненты

Если сравнивать между собой CAE и GSN, то следует отметить, что CAE уделяет больше внимания обоснованию отдельных аргументов. Для этого выполняется детальное конструирование шагов аргументации. GSN больше фокусируется на типовых структурах (паттернах) аргументов. За счет большего числа сущностей, GSN является менее строгой, и, в то же время, при более лаконичном описании она может быть сведена к CAE. Применение каждой из нотаций может быть в достаточной мере субъективным, поскольку подход к конструированию аргументов зависит от лица, которое выполняет эту задачу. Некоторые практики Assurance Case отмечают, что в нотациях существует ряд пробелов, связанных с полнотой определения элементов семантики.

Сложилось так, что на сегодняшний день более распространенной является GSN. Формат GSN закреплен в стандарте Goal Structuring Notation (GSN) Community Standard, а также в метамодели данных Structured Assurance Case Metamodel (SACM) от Object Management Group (OMG).

База знаний: отрасли, стандарты, исследования, инструменты, альтернативные нотации


Assurance Case используется, в первую очередь, в тех отраслях, в которых его применение регламентировано нормативными документами. Лидером здесь является Великобритания и некоторые другие страны Британского содружества. В отчете британской Health Foundation Using safety cases in industry and healthcare (2012) говорится об опыте нормативного применения Assurance Case (Safety Case) в здравоохранении, авиации, атомной энергетике, автомобильной, оборонной, нефтехимической и железнодорожной отраслях.

Если рассматривать требования к применению Assurance Case за пределами Великобритании, то следует отметить:
  • автомобильный стандарт ISO 26262:2011, Road vehicles Functional safety, входящий в семейство стандартов по функциональной безопасности, детализирующих требования МЭК 61508;
  • документы European Organisation for the Safety of Air Navigation (EUROCONTROL): Safety Case Development Manual, 2006, EAD (European Aeronautical Information System Database) Safety Case, 2009, EAD (European Aeronautical Information System Database) Safety Case Guidance, 2010;
  • документированную общую позицию регулирующих организаций по ядерной безопасности в области лицензирования ПО для ядерных реакторов Licensing of safety critical software for nuclear reactors Common position of international nuclear regulators and authorised technical support organisations, 2018, согласована девятью странами (Бельгия, Германия, Канада, Испания, Корея, Китай, Великобритания, Швеция, Финляндия);
  • стандарты серии ISO/IEC 15026, Systems and software engineering Systems and software assurance, которая включает четыре части: Part 1: Concepts and vocabulary (2019); Part 2: Assurance case (2011); Part 3: System integrity levels (2015); Part 4: Assurance in the life cycle (2012).

Также следует отметить ряд организаций (помимо уже упомянутых Adelard и High Integrity Systems Engineering Group из университета Йорка), которые активно работают в области Assurance Cases. К ним относятся:
  • US-CERT (United States Computer Emergency Readiness Team), свою методологию они называют Security Assurance Cases;
  • SEI/CMU (Sofrware Engineering Institute Carnegie Mellon University), в первую очередь, CERT Division, входящий в состав SEI, осуществляет исследовательскую и академическую поддержку для развития методологии Assurance Case и активно сотрудничает с US-CERT;
  • NASA (National Aeronautics and Space Administration) в рамках программы Scientific and Technical Information (STI) применяет Assurance Case для оценивания безопасности беспилотников и некоторых космических аппаратов;
  • среди всех академических публикаций, на мой взгляд, своей практической направленностью выделяются исследования John Rushby, выполненные по программам исследовательского института SRI International (бывший Stanford Research Institute), и особенно, отчет The Interpretation and Evaluation of Assurance Cases, к которому мы еще обратимся.

Из программных средств поддержки Assurance Case наиболее известным остается Adelard ASCE (Case Case and Safety Case Environment). Большинство проектов, упоминаемых в разные годы, так и не вышли на какой-либо серьезный уровень. NASA заявило о создании ПО AdvoCATE, но они применяют его в собственных целях, и не планируют выпускать на рынок. Учитывая простоту нотации, для составления диаграмм Assurance Case и их дополнения гиперссылками можно использовать, например, MS Visio.

Из альтернативных подходов к разработке Assurance Case можно также упомянуть программный инструмент NOR-STA. Он бы разработан польской компанией Argevide (spinoff Гданьского технологического университета). NOR-STA поддерживает собственную нотацию TRUST-IT. Разница состоит в том, что вместо графического представления NOR-STA использует структурированный иерархический список (Рисунок 6).



Рисунок6. Нотация Trust-IT: основные компоненты и пример использования

Сущности в иерархическом списке целей Assurance Case обозначаются разными значками. Для подтверждения соответствия заявлению используется стратегия аргументации, а факты или наблюдения, обоснования, предположения и дополнительные утверждения используются в качестве аналога подтверждений. В отличие от десктопного Adelard ASCE, NOR-STA используется онлайн и поддерживает распределенную командную работу.

Кроме того, Assurance Case применяется для решения следующих прикладных задач:
  • оценивание атрибутов комплексных свойств, таких, как Quality, Dependability, Security;
  • поддержка сертификации и стандартизации путем преобразование требований стандартов в структуру аргументов;
  • Assurance Based Development (ABD) или разработка продукта, основанная на гарантиях, является разновидностью Model-Based Development (MBD);
  • управление знаниями, например, моделирования структуры документации либо определение структурных связей в какой-либо области деятельности (бизнес процессы, документооборот, управления изменениями и т.д.).

Применение Assurance Case в области информационной безопасности


Security (Trustworthiness) Case известен, как одна из разновидностей Assurance Case. При необходимости, Security Case может быть дополнен компонентами Safety Case. Собственно говоря, идея Assurance Case и состоит в объединении атрибутов safety & security. В области сертификации существуют наработки для стандарта ISO/IEC 15408 (Общие критерии), для которого было выполнено преобразование требований в структуру, совместимую со структурой Assurance Case. Такое преобразование может быть выполнено и для других релевантных стандартов, например, для ISO 27000, или IEC 62443, или любых других фреймворков.

В качестве примера приведен фрагмент Security Assurance Cases, размещенный на сайте US-CERT. В этом фрагменте рассмотрено подтверждение реализации безопасного цикла разработки ПО (Software Development Life Cycle, SDLC). Фокус сделан на устранение дефектов кодирования (в частности Buffer Overflow), для чего применяются такие методы, как обучение программистов, ревью кода, статический анализ и тестирование. Можно, конечно, поспорить с полнотой этого фрагмента, но он приведен лишь в качестве иллюстрации (Рисунок 7).


Рисунок 7. Фрагмент Security Assurance Cases

Таким образом, хотя информационная безопасность это то приложение, где Assurance Case мог бы быть наиболее востребованным, следует констатировать, что несмотря на свой потенциал и ряд пилотных исследований, Assurance Case не стал общеизвестной практикой в этой области.

Пример практического применения Assurance Case


И, наконец, давайте рассмотрим на примере, как это все может работать. В основу положен подход, основанный на разработке структурированных аргументов.

Структурированные аргументы


Представим процесс разработки аргументов в виде двух последовательных шагов (Рисунок 8). Первый шаг, называемый шагом рассуждения (Reasoning Step, RS), это анализ подцелей (SC), которые направлены на достижение основной цели (С). На этом шаге развивается структура аргументации. На втором шаге, называемом шагом подтверждения (Evidential Step, ES), формулируются подтверждения (Evidece, E) в поддержку подцелей (SC), выработанных на предыдущем шаге. Для дальнейшей формализации шагов RS и ES используются типовые шаблоны структурированного текста (Structured Text, ST).


Рисунок 8. Шаги и компоненты структурированных аргументов

Иерархия требований


Представим иерархию или пирамиду требований, которые образуют структуру, соответствующую графу Assurance Case. В большинстве нормативных требований к компьютерным системам или к ПО структура требований включает 3 или 4 уровня (Рисунок 9).


Рисунок 9. Иерархия требований и ее связь с шагами аргументации

Нулевой уровень это мета-цель, согласно которой оцениваемая система должна соответствовать всем требованиям безопасности. На первом уровне достигаются глобальные цели безопасности, например, из требований МЭК 61508 к функциональной безопасности вытекают следующие цели:
  • должна быть реализована система управления безопасностью;
  • во время разработки системы (или ПО) должен быть применен жизненный цикл безопасности;
  • для системы должен быть применен достаточный комплекс мер защиты от случайных отказов;
  • для системы (или ПО) должен быть применен достаточный комплекс мер защиты от систематических и программных отказов, включая защиту от кибератак.

На втором уровне группы требований поддерживают ту или иную глобальную цель. Например, требования к управлению безопасностью (согласно МЭК 61508) включают группы требований к управлению персоналом, управлению конфигурацией, управлению документацией и другие. Структура связей между нулевым, первым и вторым уровнями представляет собой достаточно простое дерево. Такая структура не требует детальной проработки аргументов, поскольку аргументы эти являются типовыми и многократно проверенными в различных проектах. Однако при переходе со второго уровня на более низкие требуются структурированные аргументы. При этом требования нижних уровней могут быть составными (то есть, включать ряд отдельных требований) или простыми (атомарными). Если все требования атомарные (составные требования отсутствуют), то данный уровень становится третьим, и тогда он напрямую связан с подгруппами требований. Если имеются составные требования, то получаем более сложную четырехуровневую структуру.

Для самого нижнего уровня, помимо RS, также следует применять ES. Поскольку неудобно добавлять подробную информацию о содержании аргументов в структуру графа, каждый из узлов графа Assurance Case, начиная со второго уровня, размечается описанием аргументов с использованием структурированного текста (ST). Граф Assurance Case на нижнем уровне уже не является деревом, потому что одно и то же подтверждение (E) может поддерживать разные подцели (SC).

Assurance Case для группы требований к управлению персоналом (МЭК 61508)


В качестве иллюстрации рассмотрим фрагмент Assurance Case применительно к требованиям МЭК 61508 к управлению персоналом (МЭК 61508-1, раздел 6).

Структурированный текст, описывающий и объединяющий шаги рассуждения (RS) для всех релевантных требований
Reasoning Step (Human Resource Management)
Context
Connection between the group of Human Resource Management requirements of the Assurance Case Level 2 and composite and separate requirements of Level 3
Docs
Human Resource Management Plan
Claim
Human Resource Management complies with IEC 61508 requirements
Subclaim SC1 (IEC 61508-1, 6.2.1), SEPARATE
Persons responsible for specific activities shall be appointed
Subclaim SC2 (IEC 61508-1, 6.2.3), SEPARATE
Project participants shall understand their roles and responsibilities
Subclaim SC3 (IEC 61508-1, 6.2.4), SEPARATE
Communications of the project participants shall be defined
Subclaim SC4 (IEC 61508-1, 6.2.13), SEPARATE
Evaluation and assurance of the project participants competencies shall be performed
Subclaim SC5 (IEC 61508-1, 6.2.14a,,k), COMPOSITE
Competencies shall be considered in relation to the particular application, taking into account all relevant factors
Subclaim SC6 (IEC 61508-1, 6.2.15), SEPARATE
Competencies of all responsible persons shall be documented
Subclaim SC7 (IEC 61508-1, 6.2.16), SEPARATE
Human resource management activities shall be implemented and monitored
Justification
Structure and content of the Human Resource Management Plan
END Reasoning Step

Всего из МЭК 61508 было извлечено семь требований, связанных с управлением персоналом. С точки зрения структурированной аргументации, эти требования являются подцелями (SС1,,SС7). Лишь одна из подцелей (SС5) является составной, все остальные атомарные. Для того, чтобы перейти от составной подцели (SС5) к атомарным (SС5.1,,SC5.11), выполняется еще один шаг рассуждения (RS). При этом подразумевается, что согласно требованиям МЭК 61508, для проекта, связанного с созданием какого-либо абстрактного продукта, был разработан Human Resource Management Plan. Этот план интерпретирует требования стандарта в контексте проекта.

Структурированный текст для шагов подтверждения (ES)
Evidential Step ES1,,ES6
Context
Connection with the subclaims of the Levels 3 and the Level 4
Docs
Human Resource Management Plan; Communications Plan; Training Plans; Training Reports
Claim
SC1,, SC7
Evidence E1
Organizational Chart
Evidence E2
Project Roles Description
Evidence E3
Participants and Signature List
Evidence E4
Participants Communications Plan
Evidence E5
Competency Matrix
Evidence E6
Training Plans and Reports
Claim -> Evidence
SC1 -> E1&E2; SC2 -> E3; SC3 -> E4; SC4 -> E5&E6; SC5 -> E5&E6; SC6 -> E5&E6; SC7 -> E1&E2
Justification
Structure and content of E1,,E6
END Evidential Step

Для выполнения всех шагов подтверждения (ES) предлагается использовать общий структурированный текст с указанием связей между подцелями (SG) подтверждениями (E). Будем использовать отношение SG -> E, чтобы обозначить взаимосвязь между соответствующей подцелью (SG) и поддерживающими ее подтверждениями (E).

Анализ составного требования SC5
Требование SС5 включает список с одиннадцатью атомарными требованиями. Все эти требования связаны с компетенциями должностных лиц, поэтому они могут быть покрыты общим шагом подтверждения (ES). Таким образом, наличие составной подцели принципиально не влияет на содержание шагов рассуждения (RS) и подтверждения (ES). Для упрощения работы с составными подцелями предлагается операция свертки.



Мы можем свернуть двухуровневые шаги рассуждения (RS), если атомарные требования, связанные с общим составным требованием, поддерживаются одним и тем же шагом подтверждения (ES).

Все полученные отношения SG -> E могут быть трансформированы в граф Assurance Case, согласно нотации GSN, модифицированной для структурированной аргументации (Рисунок 10). Этот граф отражает всю группу требований, связанных с управлением персоналом согласно МЭК 61508. Также данный граф можно использовать в качестве шаблона для выполнения оценивания на соответствие требованиям МЭК 61508.


Рисунок 10. Граф Assurance Case, полученный на основе структурированных аргументов для группы требований по управлению персоналом (МЭК 61508)

На первый взгляд все это долго и сложно, но, тем не менее, Assurance Case имеет свое практическое применение. Именно такой подход мы использовали при сертификации ПЛК RdICS на соответствие МЭК 61508.

Заключение


Метод Assurance Case (Safety Case) применяется на протяжении более 20 лет для анализа безопасности объектов КИИ. Наибольшее распространение данный метод получил в Великобритании и ряде стран Британского содружества для таких отраслей, как здравоохранение, авиация, атомная энергетика, автомобилестроение, оборонная, нефтехимическая и железнодорожная промышленность.

К достоинствам Assurance Case следует отнести все плюсы, достигаемые визуализацией отношений в сложной предметной области, за счет улучшения нашего восприятия и понимания. Недостатки обусловлены субъективностью метода в части его зависимости от экспертности лиц, выполняющих оценивание. Наиболее известный epic fail в применении Assurance Case описан здесь. Вкратце: 2 сентября 2006 г. в Афганистане произошел пожар на борту самолета Nimrod Британских ВВС. Проблема возникла из-за утечки топлива. Погибли все 14 человек, находившиеся на борту. Выпущенный ранее отчет Safety Case подтверждал безопасность воздушного судна. Расследование показало, что на серийных самолетах была не вполне корректно выполнена модификация топливной системы, и подобные проблемы возникали раньше, но почему-то никто не обратил на них внимания, как на системную ошибку. В выпущенном 600-страничном отчете это происшествие было названо не иначе, как a failure of leadership, culture and priorities.

К слову, графические нотации в отчете для Nimrod не использовались. Одним из последствий этой катастрофы стало углубление исследований именно в области построения аргументации. Впрочем, удовлетворяющий всех общий подход так и не был выработан.

На сегодняшний день основным драйвером внедрения Assurance Case являются нормативные и законодательные требования, а вовсе не удобство, целесообразность или экономическая эффективность. Очевидно, что в области Assurance Case открываются большие возможности для искусственного интеллекта, но что-то мне не встречались публикации на данную тему.
Тем не менее, проблема, связанная с оцениванием безопасности сложных систем, остается открытой. Возможно, что определенный прогресс в этой области может быть достигнут при активном внедрении Assurance Case, ведь этот метод опирается на все те важные моменты, которые занимали человечество с самого начала философских исследований.
Подробнее..

Дешифрация протокола Орион Bolid

19.06.2021 06:09:13 | Автор: admin

Компания Bolid лидер в разработке интегрированных систем безопасности - то, что вы услышите, если позвоните им по телефону. Это своего рода российский Apple в сфере АСУТП, со своей закрытой экосистемой. Попробуем немного открыть экосистему.

Введение

Большая часть устройств Bolid обычно связывается между собой двумя проводами через RS-485 в большинстве случаев с параметрами 9600/8-N-1.

Для общения используются 2 шифрованных протокола: Орион или Орион Про. На момент написания статьи я пока не знаю в чём между ними разница, во всяком случае дальше будет речь о протоколе Орион (без Про).

Существует устройство С2000-ПП от компании Bolid для общения с bolid-устройствами через протокол Modbus-RTU. Но его функционал крайне ограничен.

Протокол Орион

Протокол Орион представляет из себя подобие Modbus-RTU, есть команда, количество передаваемых байт и CRC.

Мы общаемся со slave-устройствами как master, мы отправляем запросы, устройства нам отвечают.

Некоторые команды передаются в шифрованном виде, некоторые в открытом. Хорошим индикатором шифрованной команды является смещённый адрес в начале сообщения. У шифрованного сообщения смещение адреса идёт на 0x80 или 0d128. Как итог 127 возможных адресов + 128 число смещения = 255 (максимальное значение одного байта из 2^8 возможных).

Для того, чтобы устройства отвечали на шифрованные сообщения, необходимо задать глобальный ключ - GLOBAL_KEY для каждого устройства, хотя бы единожды (не проверял какой стоит по умолчанию).

При отправке шифрованных команд используется MESSAGE_KEY при каждом запросе.

Для общения с Bolid-устройствами нам нужно подключиться в любое место линии RS-485 (не забываем про терминаторы, иногда без них работа нестабильна).

Расчёт контрольной суммы

Для расчёта CRC используется CRC-8-Dallas, рассчитываемый табличным методом.

byte[] CrcTable = {            0x00,0x5E,0xBC,0xE2,0x61,0x3F,0xDD,0x83,0xC2,0x9C,0x7E,0x20,0xA3,0xFD,0x1F,0x41,            0x9D,0xC3,0x21,0x7F,0xFC,0xA2,0x40,0x1E,0x5F,0x01,0xE3,0xBD,0x3E,0x60,0x82,0xDC,            0x23,0x7D,0x9F,0xC1,0x42,0x1C,0xFE,0xA0,0xE1,0xBF,0x5D,0x03,0x80,0xDE,0x3C,0x62,            0xBE,0xE0,0x02,0x5C,0xDF,0x81,0x63,0x3D,0x7C,0x22,0xC0,0x9E,0x1D,0x43,0xA1,0xFF,            0x46,0x18,0xFA,0xA4,0x27,0x79,0x9B,0xC5,0x84,0xDA,0x38,0x66,0xE5,0xBB,0x59,0x07,            0xDB,0x85,0x67,0x39,0xBA,0xE4,0x06,0x58,0x19,0x47,0xA5,0xFB,0x78,0x26,0xC4,0x9A,            0x65,0x3B,0xD9,0x87,0x04,0x5A,0xB8,0xE6,0xA7,0xF9,0x1B,0x45,0xC6,0x98,0x7A,0x24,            0xF8,0xA6,0x44,0x1A,0x99,0xC7,0x25,0x7B,0x3A,0x64,0x86,0xD8,0x5B,0x05,0xE7,0xB9,            0x8C,0xD2,0x30,0x6E,0xED,0xB3,0x51,0x0F,0x4E,0x10,0xF2,0xAC,0x2F,0x71,0x93,0xCD,            0x11,0x4F,0xAD,0xF3,0x70,0x2E,0xCC,0x92,0xD3,0x8D,0x6F,0x31,0xB2,0xEC,0x0E,0x50,            0xAF,0xF1,0x13,0x4D,0xCE,0x90,0x72,0x2C,0x6D,0x33,0xD1,0x8F,0x0C,0x52,0xB0,0xEE,            0x32,0x6C,0x8E,0xD0,0x53,0x0D,0xEF,0xB1,0xF0,0xAE,0x4C,0x12,0x91,0xCF,0x2D,0x73,            0xCA,0x94,0x76,0x28,0xAB,0xF5,0x17,0x49,0x08,0x56,0xB4,0xEA,0x69,0x37,0xD5,0x8B,            0x57,0x09,0xEB,0xB5,0x36,0x68,0x8A,0xD4,0x95,0xCB,0x29,0x77,0xF4,0xAA,0x48,0x16,            0xE9,0xB7,0x55,0x0B,0x88,0xD6,0x34,0x6A,0x2B,0x75,0x97,0xC9,0x4A,0x14,0xF6,0xA8,            0x74,0x2A,0xC8,0x96,0x15,0x4B,0xA9,0xF7,0xB6,0xFC,0x0A,0x54,0xD7,0x89,0x6B,0x35        };

Вариант расчёта CRC:

byte сalculate_сrc(byte[] inputMessage){            byte crc = 0;            if (inputMessage.Count == 0)            {                return 0;            }            var length = inputMessage.Count;            for (int i = 0; i < length; ++i)            {                crc = CrcTable[crc ^ inputMessage[i]];            }            return crc;}

Вариант расчёта CRC:

byte CalculateCrc(IList<byte> inputMessage){            return inputMessage.Aggregate((byte)0, (prev, next) => CrcTable[prev ^ next]);}

Установка глобального ключа

Для того, чтобы общаться с каким-то устройством, ему нужно задать глобальный ключ (для забавы и наглядности выбран ключ 0xBA, получается BABA).

Далее по тексту операция исключающего или (XOR) будет обозначаться символом ^.

Зададим Bolid-устройству с адресом 3 глобальный ключ следующей командой:

0x03 0x06 0x00 0x11 0xBA 0xBA 0x8D
  • 0x03 - адрес Bolid-устройства, в данном случае устройство имеет адрес 3 (из возможных 1..127);

  • 0x06 - количество передаваемых байт (итоговая длина сообщения минус один);

  • 0x00 - GLOBAL_KEY ^ MESSAGE_KEY (в данном случае GLOBAL_KEY = MESSAGE_KEY, поэтому GLOBAL_KEY ^ MESSAGE_KEY == 0);

  • 0x11 - команда на запись нового ключа устройства;

  • 0xBA - новый GLOBAL_KEY;

  • 0xBA - новый GLOBAL_KEY (повтор байта, видимо на всякий случай);

  • 0x8D - контрольная сумма CRC-8.

Считаем статус устройства

Для того, чтобы получить текущий статус устройства, отправим следующую команду:

0x83 0x08 0x00 0xED 0xB8 0xBA 0xBA 0xBA 0x62
  • 0x83 - ADDRESS + 0x80(смещение адреса при шифровании) (ADDRESS == 3);

  • 0x08 - количество передаваемых байт (итоговая длина сообщения минус один);

  • 0x00 - GLOBAL_KEY ^ MESSAGE_KEY (они одинаковые, поэтому ноль);

  • 0xED - 0x57 ^ MESSAGE_KEY команда на чтение статуса;

  • 0xB8 - 0x02 ^ MESSAGE_KEY команда на чтение статуса;

  • 0xBA - MESSAGE_KEY;

  • 0xBA - MESSAGE_KEY;

  • 0xBA - MESSAGE_KEY;

  • 0x62 - контрольная сумма CRC-8.

На данную команду мы можем получить ответ навроде:

0x83 0x0A 0xE2 0xB8 0xBA 0xBE 0xB9 0x7D 0x2F 0x72 0xD7
  • 0x83 - ADDRESS + 0x80 (ADDRESS == 3);

  • 0x0A - количество передаваемых байт (итоговая длина сообщения минус один);

  • 0xE2 - 0x88 ^ MESSAGE_KEY - назначение байта мне не известно;

  • 0xB8 - 0x02 ^ MESSAGE_KEY - назначение байта мне не известно;

  • 0xBA - MESSAGE_KEY;

  • 0xBE - 0x04 ^ MESSAGE_KEY - назначение байта мне не известно;

  • 0xB9 - 0x03 ^ MESSAGE_KEY - назначение байта мне не известно;

  • 0x7D - STATUS_1(0xC7) ^ MESSAGE_KEY;

  • 0x2F - STATUS_2(0x95) ^ MESSAGE_KEY;

  • 0x72 - 0xC8 ^ MESSAGE_KEY - назначение байта мне не известно;

  • 0xD7- контрольная сумма CRC-8.

Мы получили 2 статуса STATUS_1 и STATUS_2:

0xC7 и 0x95

199 и 149, соответственно.

Статус 199 - это Восстановление источника питания;

Статус 149 - это Взлом корпуса прибора.

Полный перечень статусов можно взять из документации на С2000-ПП.

Ссылка на одноимённую тему форума cxem.net

Подробнее..

Из песочницы Как я при помощи Google сделал OPC2WEB клиент

14.11.2020 18:04:39 | Автор: admin
Я работаю инженером АСУТП и немного увлекаюсь программированием: при помощи Гугла и Stack Overflow делал несколько калькуляторов на HTML и javascript, делал бота для телеграма на php, даже немного программировал на c# по работе. В этот раз задача была куда интереснее и сложнее, хотя и звучала просто: хочу видеть в своем браузере текущую скорость агрегата. Для начала я решил попробовать поискать готовый софт: естественно такое уже давно придумано, есть готовые и даже бесплатные SCADA системы, которые могут работать и в качестве веб сервера, но они все были сильно наворочены и сложны для моего понимания, к тому же нужно было просто вывести скорость. Поэтому я подумал что можно попробовать сделать это самому и вот что из этого вышло:

Backend


После того как я решил что буду делать сам, снова открыл поисковик и стал искать как самому сделать свой OPC клиент.



Поиски этого привели меня на хабр, где я узнал про бесплатную библиотеку OPCDOTNET. В архиве библиотеки лежал исходник консольного клиента, который я скомпилировал на своем компьютере, запустил простой OPC симулятор (gray-box) и о чудо! я увидел в консоли изменяющиеся числа. Это значит, что теперь я смогу их отправлять в качестве ответа по вебзапросу. Следующим заходом в гугл стал запрос простого веб сервера где наткнулся на пример использования HttpListener. Запустил пример в отдельном проекте, понял как это работает, и стал добавлять все это к своему OPC клиенту. Через много попыток компиляций, поиска ошибок на Stack Overflow у меня все же получилось увидеть в браузере заветную скорость. Это была победа! Но я сразу же понял, что одна лишь скорость это не серьезно, через время технологи захотят увидеть и другие параметры линии, поэтому нужно придумать как добавлять необходимые сигналы, без изменения программы. На помощь пришли файлы конфигурации, где можно заранее задать какие сигналы хотим видеть, задать порт прослушивания сервера, время обновления и прочее. Опыт в создании файлов конфигурации уже имелся, поэтому сделал так как ранее делал и проверенно работало. Так же в процессе пришлось обратиться к другу программисту, который подсказал что сделать чтобы передавался полный массив запрашиваемых данных, а не только те значения что менялись (в готовом примере OPC клиента в консоли отображались только изменяемые значения).



После таких изменений программа стала генерировать таблицу в HTML из запрашиваемых в конфиге сигналов: обратившись через браузер по адресу сервера, где был запущен этот клиент, теперь можно было видеть таблицу, в которой были названия сигналов и значения в соседнем столбце. Это было уже неплохо, но значения при обновлении промаргивали, а сами сигналы тупо располагались друг за другом хоть и были структурированы в виде таблицы. Кстати, чтобы значения обновлялись автоматически ежесекундно, а не только когда пользователь обновит страницу, я добавил в возвращаемую на запрос страницу тег meta с параметром Refresh. Но мне очень хотелось чтобы значения обновлялись автоматически и без перезагрузки страницы, поэтому нужно было кроме бэкенда теперь делать и фронт: пользователь запрашивает страницу на сервере, внутри которой происходит запрос к клиенту, и страница после этого генерирует все это в красивом и понятном виде, где можно структурировать данные как заблагорассудится, поменять цвета, шрифты и размеры сделать можно вообще все что угодно при таком-то подходе.

Frontend


Пришел я к этому не сразу: сначала стал гуглить как сделать так чтобы данные на странице обновлялись без перезагрузки. Как выяснилось нужно использовать AJAX, то есть изменять данные через javascript, а принимать их через JSON. В клиенте простой конкатенацией строк сделал генерацию JSON, причем для универсальности решил просто отсчитывать по порядку задаваемые в конфиге теги. Потом нашел пример в котором через javascript запрашивается ежесекундно JSON строка и выводятся значения из нее. Поменяв код под свои нужды и запустив страницу я увидел что все работает данные обновляются без перезагрузки страницы (!). Это была еще одна победа. Теперь оставалось дело за малым грамотно распределить на странице полученные данные, то есть сделать что-то в виде визуализации. Сначала я решил сделать так же таблицу, но потом понял что блочная структура смотрится красивее и функциональнее. Блоки можно окрашивать в разные цвета и менять их размер. А еще нужно сделать так чтобы пользователь мог самостоятельно добавлять и изменять структуру, не буду же я на каждую новую хотелку переписывать HTML файл. В итоге получился такой вот вариант, как на картинке ниже.



Здесь можно добавлять большие блоки, которые будут объединять малые блоки с одним признаком. Такие большие блоки можно озаглавливать так как нужно, менять их цвета (если щелкнуть по блоку с зажатой клавишей shift) и менять их размер. Блоки со значениями добавляются при двойном клике по большому блоку. В них так же можно задавать свои названия и единицы измерения. Если нечаянно добавил не тот элемент или не туда, то можно удалить его я подсмотрел эту функцию в одном букмарклете, полностью перенеся его код на страницу. Конечно вся созданная структура после перезагрузки страницы исчезнет и для ее сохранения нашел такую возможность как локальное хранилище. А для того чтобы перенести готовую структуру на другой компьютер сделал импорт и экспорт экрана из локального хранилища.

Единственная проблема оставалась с перетаскиванием блоков хотелось бы сделать красиво drag and drop, но для меня это оказалось непосильно. Вышел из ситуации так: если открыть страницу в панели разработчика в хроме, то блоки можно перетаскивать. Это натолкнуло на мысль что задействовав правую кнопку мыши можно просто менять блоки местами. Сейчас такая система вполне универсальная: чтобы добавить новый сигнал нужно просто добавить нужный OPC тег в конфиг и перезапустить клиента. Добавленный тег автоматически добавляется в JSON и на экране вывода появляется внизу новое значение, которое можно несколькими кликами добавить в существующий или новый блок на странице. На данный момент на странице выводится больше 60 тегов и больше половины из них добавлял уже не я, то есть процесс добавления может и не самый простой, но не требует переписывания программы и страницы вывода. Протестировать и посмотреть код этой страницы можно тут

Заключение


Поскольку данная статья должна быть вроде инструкции, как непрограммист вроде меня с помощью поисковиков может сделать что-то полезное, то наверное нужно добавить немного слов о том как именно я искал информацию. Тут впору говорить как на картинке в самом начале: думаешь что ты хочешь получить и спрашиваешь об этому у гугла, а если что-то где-то не получается, то смотришь на коды ошибок и спрашиваешь снова. Очень помогает поиск на английском языке даже вбив просто ключевые слова можно получить ссылку на подобную решенную проблему на стаковерфлоу с вероятностью 80%. Для поиска готовых примеров, код из которого можно тупо взять и перенести в свою программу, можно добавлять такие ключевые слова как example или по-русски пример. Несколько хороших идей нашлось на хабре, то есть можно попробовать в запрос вставить ключевое слово habr, но я таким пользовался только тогда когда точно знал что на хабре видел решение которое ищу. Практически любая мелкая задача из всего того, что было сделано, решалась через поисковик: change div color shift click js, make div resizeable, как редактировать веб страницу сотня вариаций разных запросов. Возможно в комментариях профи могут поделиться своими советами.

И да, раз уж речь зашла о советах, то мне бы еще хотелось получить от вас конструктивную критику и полезные советы. Возможно кто-то захочет размять мозги и сможет за пару часов накидать куда более функциональное решение. Или может кого-то этот пост натолкнет на интересные идеи, ведь таким способом можно принимать любой JSON запрос и сделать на его основе любую визуальную структуру. Было бы очень круто заиметь похожее универсальное решение, где можно любые данные распределять так как тебе это удобно, управляя простыми визуальными формами, drag and drop, resize и все такое прочее, чтобы красиво и функционально, а не вот это вот все. Хотя и так получилось неплохо, я считаю. Скорость агрегата, как и просил заказчик, теперь можно наблюдать из браузера и добавить что-то новое не составит большого труда.

Ссылка на код клиента на C#

Либо под спойлером
/*=====================================================================  File:      OPCCSharp.cs  Summary:   OPC sample client for C#-----------------------------------------------------------------------  This file is part of the Viscom OPC Code Samples.  Copyright(c) 2001 Viscom (www.viscomvisual.com) All rights reserved.THIS CODE AND INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANYKIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THEIMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR APARTICULAR PURPOSE.======================================================================*/using System;using System.Threading;using System.Runtime.InteropServices;using System.Configuration;using OPC.Common;using OPC.Data;using System.Net;using System.Globalization;using System.Data.SqlClient;using System.Data;using System.Net.Sockets;namespace CSSample{    class Tester    {        // ***********************************************************EDIT THIS :        string serverProgID = ConfigurationManager.AppSettings["opcID"];         // ProgID of OPC server        private OpcServer theSrv;        private OpcGroup theGrp;        private static float[] currentValues;        private static string responseStringG ="";        private static HttpListener listener = new HttpListener();        private static string consoleOut = ConfigurationManager.AppSettings["consoleOutput"];        private static string answerType = ConfigurationManager.AppSettings["answerType"];        private static string portNumb = ConfigurationManager.AppSettings["portNumber"];        private static int timeref = Int32.Parse(ConfigurationManager.AppSettings["refreshTime"]);        private static string[] tagsNames = ConfigurationManager.AppSettings["tagsNames"].Split(','); // tags from config        private static string[] ratios = ConfigurationManager.AppSettings["ratios"].Split(',');        private static string sqlSend = ConfigurationManager.AppSettings["sqlSend"];        private static string udpSend = ConfigurationManager.AppSettings["udpSend"];        private static string webSend = ConfigurationManager.AppSettings["webSend"];        private static string table_name = ConfigurationManager.AppSettings["table"]; // название таблицы из конфига;        private static string column_name = ConfigurationManager.AppSettings["column"];        private static int sendtags = Int32.Parse(ConfigurationManager.AppSettings["tags2send"]);                private static IPAddress remoteIPAddress = IPAddress.Parse(ConfigurationManager.AppSettings["remoteIP"]); // Ip from config        private static int remotePort = Convert.ToInt16(ConfigurationManager.AppSettings["remotePort"]); // remote port from config        public static SqlConnection myConn = new SqlConnection(ConfigurationManager.ConnectionStrings["connstr"].ConnectionString); //строка соединения с SQL которая берется из конфига        SqlCommand myCommand = new SqlCommand("Command String", myConn);        public void Work()        {            /*try// disabled for debugging                {*/            theSrv = new OpcServer();            theSrv.Connect(serverProgID);            Thread.Sleep(500);              // we are faster then some servers!            // add our only working group            theGrp = theSrv.AddGroup("OPCCSharp-Group", false, timeref);            string[] tags = ConfigurationManager.AppSettings["tags"].Split(','); // tags from config            if (sendtags > tags.Length) sendtags = tags.Length;                var itemDefs = new OPCItemDef[tags.Length];            for (var i = 0; i < tags.Length; i++)            {                itemDefs[i] = new OPCItemDef(tags[i], true, i, VarEnum.VT_EMPTY);            }            OPCItemResult[] rItm;            theGrp.AddItems(itemDefs, out rItm);            if (rItm == null)                return;            if (HRESULTS.Failed(rItm[0].Error) || HRESULTS.Failed(rItm[1].Error))            {                Console.WriteLine("OPC Tester: AddItems - some failed"); theGrp.Remove(true); theSrv.Disconnect(); return;            };            var handlesSrv = new int[itemDefs.Length];            for (var i = 0; i < itemDefs.Length; i++)            {                handlesSrv[i] = rItm[i].HandleServer;            }            currentValues = new Single[itemDefs.Length];            // asynch read our two items            theGrp.SetEnable(true);            theGrp.Active = true;            theGrp.DataChanged += new DataChangeEventHandler(this.theGrp_DataChange);            theGrp.ReadCompleted += new ReadCompleteEventHandler(this.theGrp_ReadComplete);            int CancelID;            int[] aE;            theGrp.Read(handlesSrv, 55667788, out CancelID, out aE);            // some delay for asynch read-complete callback (simplification)            Thread.Sleep(500);            while (webSend=="yes")            {                HttpListenerContext context = listener.GetContext();                HttpListenerRequest request = context.Request;                HttpListenerResponse response = context.Response;                context.Response.AddHeader("Access-Control-Allow-Origin", "*");                byte[] buffer = System.Text.Encoding.UTF8.GetBytes(responseStringG);                // Get a response stream and write the response to it.                response.ContentLength64 = buffer.Length;                System.IO.Stream output = response.OutputStream;                output.Write(buffer, 0, buffer.Length);                // You must close the output stream.                output.Close();            }            // disconnect and close            Console.WriteLine("************************************** hit <return> to close...");            Console.ReadLine();            theGrp.ReadCompleted -= new ReadCompleteEventHandler(this.theGrp_ReadComplete);            theGrp.RemoveItems(handlesSrv, out aE);            theGrp.Remove(false);            theSrv.Disconnect();            theGrp = null;            theSrv = null;            /*}            catch( Exception e )                {                Console.WriteLine( "EXCEPTION : OPC Tester " + e.ToString() );                return;                }*/        }        // ------------------------------ events -----------------------------        public void theGrp_DataChange(object sender, DataChangeEventArgs e)        {            foreach (OPCItemState s in e.sts)            {                if (HRESULTS.Succeeded(s.Error))                {                    if (consoleOut == "yes")                    {                        Console.WriteLine(" ih={0} v={1} q={2} t={3}", s.HandleClient, s.DataValue, s.Quality, s.TimeStamp); // выводит данные при изменении в консоль                    }                    currentValues[s.HandleClient] = Convert.ToSingle(s.DataValue) * Single.Parse(ratios[s.HandleClient], CultureInfo.InvariantCulture.NumberFormat); //добавляет в массив измененное значение тега                }                else                    Console.WriteLine(" ih={0}    ERROR=0x{1:x} !", s.HandleClient, s.Error);            }            string responseString = "{";            if (answerType == "table")            {                responseString = "<HTML><head><meta charset=\"UTF-8\"><meta http-equiv=\"Refresh\" content=\"" + timeref / 1000 + "\"/></head>" +            "<BODY><table border><tr><td>" + string.Join("<br>", tagsNames) + "</td><td >" + string.Join("<br>", currentValues) + "</td></tr></table></BODY></HTML>";                responseStringG = responseString;            }            else            {                for (int i = 0; i < currentValues.Length - 1; i++) responseString = responseString + "\"tag" + i + "\":\"" + currentValues[i] + "\", ";                responseString = responseString + "\"tag" + (currentValues.Length - 1) + "\":\"" + currentValues[currentValues.Length - 1] + "\"}";                responseStringG = responseString;            }            byte[] byteArray = new byte[sendtags * 4];            Buffer.BlockCopy(currentValues, 0, byteArray, 0, byteArray.Length);            if (sqlSend == "yes")            {                try                {                    SqlCommand cmd = new SqlCommand("INSERT INTO " + table_name + " (" + column_name + ") values (@bindata)", myConn);                    myConn.Open();                    var param = new SqlParameter("@bindata", SqlDbType.Binary)                    { Value = byteArray };                    cmd.Parameters.Add(param);                    cmd.ExecuteNonQuery();                    myConn.Close();                }                catch (Exception err)                {                    Console.WriteLine("SQL-exception: " + err.ToString());                    return;                }            }            if (udpSend == "yes")  UDPsend(byteArray);        }        private static void UDPsend(byte[] datagram)        {            // Создаем UdpClient            UdpClient sender = new UdpClient();            // Создаем endPoint по информации об удаленном хосте            IPEndPoint endPoint = new IPEndPoint(remoteIPAddress, remotePort);            try            {                sender.Send(datagram, datagram.Length, endPoint);                //Console.WriteLine("Sended", datagram);            }            catch (Exception ex)            {                Console.WriteLine("Возникло исключение: " + ex.ToString() + "\n  " + ex.Message);            }            finally            {                // Закрыть соединение                sender.Close();            }        }        public void theGrp_ReadComplete(object sender, ReadCompleteEventArgs e)        {            Console.WriteLine("ReadComplete event: gh={0} id={1} me={2} mq={3}", e.groupHandleClient, e.transactionID, e.masterError, e.masterQuality);            foreach (OPCItemState s in e.sts)            {                if (HRESULTS.Succeeded(s.Error))                {                    Console.WriteLine(" ih={0} v={1} q={2} t={3}", s.HandleClient, s.DataValue, s.Quality, s.TimeStamp);                }                else                    Console.WriteLine(" ih={0}    ERROR=0x{1:x} !", s.HandleClient, s.Error);            }        }        static void Main(string[] args)        {            string url = "http://*";            string port = portNumb;            string prefix = String.Format("{0}:{1}/", url, port);            listener.Prefixes.Add(prefix);            listener.Start();                        Tester tst = new Tester();            tst.Work();        }    }}/* add this code to app.exe.config file<?xml version="1.0" encoding="utf-8"?><configuration>  <startup>    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />  </startup>  <appSettings>    <add key="opcID" value="Graybox.Simulator" />    <add key="tagsNames" value="Line Speed,Any name,Любое имя" />    <add key="tags" value="numeric.sin.int16,numeric.sin.int16,numeric.sin.int16" />    <!-- ratios for tags -->    <add key="ratios" value="1,0.5,0.1" />    <add key="portNumber" value="45455" />    <add key="refreshTime" value="1000" />    <!-- "yes" or no to show values in console-->    <add key="consoleOutput" value="yes" />    <add key="webSend" value="no" />     <!-- "table" or json (actually any other word for json)-->    <add key="answerType" value="json" />    <add key="sqlSend" value="no" />    <add key="table" value="raw_tbl" />    <add key="column" value="data" />        <add key="udpSend" value="yes" />    <add key="remotePort" value="3310"/>    <add key="remoteIP" value="127.0.0.1"/>    <add key="tags2send" value="2" />      </appSettings>    <connectionStrings>    <add connectionString="Password=12345;Persist Security Info=True;User ID=user12345;Initial Catalog=amt;Data Source=W7-VS2017" name="connstr" />  </connectionStrings>   </configuration>     */

Подробнее..

Встраиваемый компьютер AntexGate. От прототипа к серийному производству

08.07.2020 14:22:16 | Автор: admin
image

Не так давно мы с командой разработали небольшой встраиваемый компьютер для решения задач IIoT и промышленной автоматизации. Первую статью о нашем устройстве можно посмотреть здесь.

Разрабатывать устройство решили на распространенном и оттестированном модуле Raspberry CM3+, что позволило нам создать компьютер с большими вычислительными способностями, огромным сообществом и простотой его использования. Под катом расскажу по этапам, от чего отталкивались и к чему пришли в итоге.

Муки выбора корпуса


Для устройств даже в промышленной сфере очень важен внешний вид устройства и законченность, таким образом начались долгие поиски корпуса, подходившие под наши требования по размеру. Хотелось максимально много уместить в одну коробку и самые минимальные параметры платы получались 10*10 см.

После того, как мы заказали несколько вариантов корпусов, пришлось большее количество из них выбросить, так как они подходили только для домашних поделок и продавать их людям в таком виде не представлялось возможным. Основным претендентом на тот момент стал алюминиевый корпус с пластиковыми крышками 10*10*5 см (рисунок 1).

image
Рисунок 1 Первый вариант корпуса

Получив этот корпус в руки, было принято решение остановиться на нем. В этот же момент разработка платы подходила к концу и уже можно было по чертежам предварительно оценить, каким образом обрабатывать торцы для выводных разъемов. Однако пластиковые крышки корпуса после механической обработки сделали вид не товарным и мы опять пришли к поделке, а не к законченному коммерческому продукту.

Глянец весь быстро поцарапался и в этой блестящей рамке отверстия выглядели очень асимметрично (рисунок 2). Ожидание и реальность, как говорится.

image
Рисунок 2 Пластиковые крышки корпуса

Однако отказываться от корпуса не пришлось, потому что у производителя был такой же, но с алюминиевыми торцами, мы быстро его заказали и удивились, насколько он идеально выглядел (рисунок 3). Торцы очень красивые, матовые и бонусом была дополнительная помехозащищенность. Стоил такой корпус уже немного дороже, но красота требует жертв.

image
Рисунок 3 Металлический корпус

Вторая попытка обработать торцы была гораздо удачнее. Технологию надписей мы выбрали путём гравировки (рисунок 4), однако были недостатки которые пришлось решать. Самое главное это то, что гравер (сверло) очень маленький и нежный, скорость нанесения гравировки достаточно низкая. Плюс само сверло часто ломается. Из-за всего этого сильно растёт цена из-за потребляемой электроэнергии и трудозатрат. Также внутрь гравировки набивается грязь и постепенно окисляется алюминий, делая надписи менее заметными.

image
Рисунок 4 Гравировка металлического корпус

Эту технологию пробовали менять на лазерную гравировку, но получилось некрасиво. Лазер выжигал краску некорректно, а надписи получались темными.

В итоге мы пришли к шелкографии с запеканием в печи (рисунок 5). Эта технология оказалась самой быстрой и очень крепкой. Всё свелось к тому, чтобы заказать единожды шаблон (фотовывод) и по нему делать партию до 50 штук в день.

image
Рисунок 5 Шелкография корпуса

Исправление недоработок


С корпусом закончили, а вот с платой оставались недоработки. Задумка нашего компьютера в том, чтобы любой пользователь мог спокойно установить дополнительное оборудование в устройство, открутив четыре болта на корпусе, как в свой ноутбук. Я думаю прошли те времена, когда на корпуса клеили наклеечки Не вскрывать, потеря гарантии.

Внутри корпуса есть периферия для прошивки вычислительного модуля, SIM-карта и многое другое. Однако была одна проблема с монтажом платы в корпус, а именно выводные светодиоды на ножках, которые постоянно гнулись у наших клиентов, взявших прототипы на тест (рисунок 6).

image
Рисунок 6 Выводные светодиоды на ножках

В этой связи пришлось поменять диоды на ножках на SMD-светодиоды, которые светят в бок и проблема с установкой платы в корпус решилась, больше ничего не гнулось (рисунок 7).

image
Рисунок 7 SMD-светодиоды

Индикация была глубоко внутри корпуса и чтобы увидеть свет приходилось смотреть под прямым углом на торец. В голову пришла идея световодов из полимерных прозрачных материалов (рисунок 8). Оставалось найти бюджетный, но эстетически красивый вариант. В голову пришел молочный плексиглас с прозрачностью 20% с толщиной листа 3 мм, в первой же фирме лазерной резки подобрали диаметр миниатюрного цилиндра, он был равен диаметру отверстия в корпусе. Особенность в том, что станок при лазерной резке дает небольшой скос нижнего диаметра на 0.1 мм и таким образом мы получили мешок миниатюрных усеченных конусов с нижним диаметром 2,9 мм и верхним 3 мм, а высота была 3 мм как и толщина торцов нашего корпуса. Вставляем конус в отверстие и запрессовка крепко загоняет эти световоды в отверстие, а небольшая капелька клея с обратной стороны фиксирует их намертво.

image
Рисунок 8 Световоды из плексигласа

Итак, устройство получило эстетичный вид при небольших вложениях в корпус, однако этот путь хорош на старте производства и уменьшение издержек планируется путем изготовления подобного корпуса при наращивании производства. Литье из пластика не рассматривается в виду дорогого запуска производства и низких экранирующих способностей по сравнению с металлом.

Итог


image

Спасибо за внимание! Надеемся, что мы вдохновим читателей на переработку Ваших личных проектов в более масштабное производство с коммерческими перспективами. В нашей великой стране на полочках у инициаторов пылятся действительно нужные вещи, которые могут заменять зарубежные производства.

В следующей статье мы расскажем Вам историю тестирования и тонкости настройки mPCIe 3G-модема Huawei и mPCIe LoraWan-модуля MikroTik.
Подробнее..

Встраиваемый компьютер AntexGate 3G-модем. Полезные настройки для более стабильного интернет-соединения

03.08.2020 14:12:05 | Автор: admin
image

В сфере промышленной автоматизации существует негласная парадигма, в которой многие производители промышленного оборудования делают контроллеры отдельно, а модемы отдельно. Как правило, каждое устройство помещается в свой корпус, имеет своё питание, большие габариты и высокую стоимость. Такой вариант разделения функционала имеет свои преимущества и недостатки, но, по нашему мнению, он ведет, скорее, к бльшей коммерциализации, чем обусловлен какими-то объективными причинами. Поэтому мы решили пойти немного по другому пути и сделали универсальное устройство, которое представляет из себя свободно программируемый контроллер на базе Linux с модемом в едином корпусе. Это нам позволило в своих проектах практически совсем отказаться от привычных всем щитов автоматизации и прийти к более мобильным решениям.

Под катом этой статьи мы поделимся с Вами тонкостями настройки модема и несколькими полезными скриптами для более стабильного 3G-соединения.

Предпосылки и решения


При разработке своего устройства мы руководствовались тем, что оно должно выходить в мобильный интернет, чтобы подключаться к облачным платформам. Было два пути: напаивать модем на плату, либо использовать mPCIe-разъемы. Мы остановились на втором варианте и предусмотрели сразу два mPCIe-разъема (рисунок 1), поскольку такой вариант нам показался более интересным и гибким. Ведь установка и замена модема занимает считанные секунды, плюс для пользователя появляется необходимая вариативность и он может использовать такие комбинации mPCIe-модулей, которые ему необходимы под конкретный проект. Кроме 3G-модема это может быть LoraWan или Wi-Fi модули. Плюс ко всему mPCIe-решения зарекомендовали себя как достаточно надежные и качественные.

image
Рисунок 1 mPCIe-разъемы

В качестве основного 3G-модуля для нашего устройства мы рассматривали следующие варианты:

  • MikroTik R11e-LTE6
  • Quectel EC25-E
  • YUGA CLM920 TE5
  • HUAWEI MU709s-2p

Однако после проведения тестов наиболее предпочтительным для нас в плане надежности и соотношения цена-качество оказался модем фирмы HUAWEI (рисунок 2). Мы взяли его за основу и устанавливаем опционально в наши устройства. Поэтому в дальнейшем мы будем рассматривать настройку и скрипты относительного модема этой модели. Возможно, этот скрипт будет универсальным и будет полезен для других модемов, однако стабильность работы с другими моделями не гарантируется. Для Rasbian Buster и HUAWEI MU709s-2p всё работает отлично.

image
Рисунок 2 Модем HUAWEI MU709s-2p, установленный на плату устройства

Использование скрипта для перезагрузки 3G-модема


Для более устойчивой и безотказной работы мы написали скрипт, который будет пинговать заданный IP-адрес, а если же определенное в настройках количество пингов не прошло, то GSM-модем перезагрузится, тем самым восстанавливая зависшее сетевое соединение. Стоит отметить, что модем определяется в системе как сетевая карта lan1.

Архив со всеми необходимыми файлами можно скачать по этой ссылке. Также текст самих скриптов представим ниже.

Файл check_inet.sh необходим для проверки наличия интернет соединения. Если заданный IP-адрес не пингуется, то мы дергаем 19 ногу и перезапускаем модем по питанию. Код из себя представляет следующий вид:
#!/bin/bash#count=0;#echo "Start script"#echo 19 > '/sys/class/gpio/export'while [ true ]; do# sleep 30. /home/pi/igate.conf#echo $usb_port#echo 'AT^NDISDUP=1,1,''"'$apn'"''\r\n' #echo 'AT^NDISDUP=1,1,"internet.mts.ru"\r\n' flag=0for ((i = 1; i <= $ping_count; i++)); do#for i in {1..$ping_count}; do #делаем 5 пингов до сервера#ping -I eth1 -c 1 8.8.8.8 > /dev/null || flag=$(($flag+1))ping -I $interface -c 1 $ping_ip || flag=$(($flag+1))sleep 1doneif [ "$flag" -ge "$ping_error" ]; then #если потерь пакетов больше 3х#echo "рестарт модема - начало"#count=$((count+1))#echo $count#рестарт модемаsudo ifconfig eth1 downecho 19 > '/sys/class/gpio/export'echo out > '/sys/class/gpio/gpio19/direction'echo 0 > '/sys/class/gpio/gpio19/value'sleep 1echo 1 > '/sys/class/gpio/gpio19/value'sleep 15sudo ifconfig eth1 upsleep 1#echo -en 'AT^NDISDUP=1,1,"internet.mts.ru"\r\n' > /dev/ttyUSB3#АТ команда для записи настроек точки доступа APNecho -en 'AT^NDISDUP=1,1,''"'$apn'"''\r\n' > $usb_port#echo "рестарт модема - конец"fisleep $timeoutdone 

Файл start_inet.sh запускает check_inet.sh после перезагрузки устройства:
#!/bin/bash### BEGIN INIT INFO# Provides:          start_inet# Required-Start:    $remote_fs $syslog# Required-Stop:     $remote_fs $syslog# Default-Start:     2 3 4 5# Default-Stop:      0 1 6# Short-Description: Example initscript# Description:       This service is used to manage a servo### END INIT INFOcase "$1" in     start)        echo "Starting check_inet"        sudo /home/pi/check_inet.sh > /dev/null 2>&1 &        #/home/pi/check_inet.sh        ;;    stop)        echo "Stopping check_inet"        #killall servod        sudo kill -USR1 $(ps ax | grep 'check_inet' | awk '{print $1}')        ;;    *)        echo "Usage: /etc/init.d/check_inet start|stop"        exit 1        ;;esacexit 0

Также в архиве находится файл конфигурации igate.conf

Последовательность настройки:
1. Добавьте правило соответствия физического подключения COM-порта модема к концентратору USB. Для этого поправьте файл по следующему пути:
sudo nano /etc/udev/rules.d/99-com.rules

2. Добавьте в файл следующую строку:
KERNEL==ttyUSB*, KERNELS==1-1.5:2.4, SYMLINK+=GSM

3. Сохраните правила и перезагрузите устройство. Теперь порт Вашего модема будут определять по удобному псевдониму /dev/GSM;
4. Скачайте архив по предложенной выше ссылки, либо самостоятельно создайте файлы check_inet.sh, start_inet.sh и igate.conf;
5. Скопируйте файл check_inet.sh в папку:
/home/pi/

6. Сделайте файл check_inet.sh исполняемым:
sudo chmod +x /home/pi/check_inet.sh

7. Скопируйте файл start_inet.sh в папку:
/etc/init.d/

8. Сделайте файл start_inet.sh исполняемым:
sudo chmod +x /etc/init.d/start_inet.sh

9. Обновите конфигурацию автозагрузки выполнив команду:
sudo update-rc.d start_inet.sh defaults

10. Скопируйте файл igate.conf в папку:
/home/pi/

11. Настройте файл конфигурации. Ниже представлен файл конфигурации с комментариями:
#ip-адрес пинга. Скрипт будет пытаться пинговать этот ip-адрес, если определенное в параметре [ping_error] количество пингов не прошло, скрипт будет перезагружать GSM-модем, тем самым восстанавливая зависшее сетевое соединение.ping_ip=8.8.8.8#точка доступа APN. Это адрес точки доступа Вашего интернет-провайдера, он выдается вместе с сим-картой.apn=internet.mts.ru#период проверки соединения 3G (период пинга). Период выполнения скрипта. Каждые 30 секунд будет осуществляться проверка пингов.timeout=30#количество пингов. Общее количество пингов.ping_count=5#количество неуспешных пингов для рестарта модема. Количество неуспешных пингов, после которых необходимо выполнять перезагрузку модема. Не может быть больше чем [ping_count]. Процент потерянных пакетов нужно подбирать индивидуально в зависимости от качества покрытия сети.ping_error=3#LAN интерфейс модема. Сетевой интерфейс модема, обычно на устройстве AntexGate определяется как [eth1], посмотреть название можно выполнив команду ifconfiginterface=eth1#USB порт модема. Физический USB порт к которому подключена сетевая карта, обычно на устройстве AntexGate определяется как [ttyUSB4]usb_port=/dev/GSM


Управление скриптом


Запуск в фоновом режиме файла скрипта check_inet.sh:
/etc/init.d/start_inet.sh start

Остановить check_inet.sh:
/etc/init.d/start_inet.sh stop

Скрипт также автоматически запускается после перезагрузки устройства.

Варианты применения устройства


Рассмотрим основные задачи, под которые можно использовать устройство:
  1. Контроллер с выходом в интернет для передачи данных в облако;
  2. 3G-роутер для задач в поле;
  3. Контроллер для умного дома с резервирующим каналом 3G. То есть можно использовать LAN-порт как основной канал связи, а 3G в качестве резервного, чтобы всегда был доступ к устройству;
  4. Базовая станция LoRaWAN, то есть опрос устройств по LoRaWAN и передача данных в облако через сеть 3G или LTE;
  5. Устройство для мониторинга транспорта (подключение по CAN и стыковка с различными сервисами)

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

Ваши АСУ ни разу ни У

12.11.2020 18:15:59 | Автор: admin

АСУ автоматизированные системы управления.

АС понятно. Это ваши любимые CRMки, 1Ски, Склад, Касса, Бухгалтерия, Зарплата и Кадры и прочие программы.

А что такое управление?

Если совсем примитивно, то
Управление это процесс перемещения некого Объекта из точки А в точку Б. Где А текущее положение, Б целевая точка (Цель).
Очевидно, что переход между одинаковыми точками при разных условиях (контекстах) осуществляется разными методами. Например: перемещение по городу в дождь, снег, летом, зимой, в пробки это совсем разные способы и режимы управления автомобилем или даже вертолетом. А может метро?

Как вы уже понимаете, точка может иметь многомерную координату (или вектор состояния) в неком пространстве (необязательно 3D).

Если говорить о предприятии, то вектор состояния может быть размером в тысячи тысяч параметров (измерений) как целевой так и текущий. Большинство измерений тесно взаимосвязаны, по формулам можно выразить одну метрику через другую. Это можно использовать для упрощения/уменьшения вектора или поиска искажений в сборе данных, управления. Еще тут присутствуют вектор ошибки, помехи, прямая и обратная связь.

Параметры могут быть такими как: количество выпускаемых или продаваемых изделий, оборот за месяц, остатки на складе (причем в разрезе каждой Номенклатуры), размер средней зарплаты, размер почасовой ставки, затраты на рекламу, процент брака, чистая прибыль (причем все параметры можно свести к ней) и многие другие.

А теперь давайте подумаем

Какие из ваших программ попадают под ранее указанное определение управления?

Открою вам страшную тайну!

На наших предприятиях, в основном, обычные базы данных или, как мы их называем с коллегами набивалки.

Да. Есть набор алгоритмов, которые уменьшают количество ошибок ввода данных, чтобы не было искажения в информации, но не более того.

Даже есть аналитические отчеты, которые показывают сводную (суммируют) информацию за некий период времени и(или) в других разрезах.

А где, собственно, тут управление? Где определение текущего состояния?
Есть отчет о прибылях и убытках, дебиторка, готовые изделия, воронка продаж.
Допустим. Насколько они отражают действительность? Где постановка целей?
Хм. Гм. Эээ.
Где функции/алгоритмы достижения целей (управления)? Где функции формирования этих алгоритмов?

Мертвая тишина в зале. Катарсис. Занавес.

Ок. Поддамся. Управление в идеале это максимально точное прогнозирование ситуации.

Каким образом можно делать ЭТО?

Основываясь на опыте (для этого и существуют набивалки хранят факты, осуществляют функцию памяти), проигрываем ситуацию в будущее. Продавцы знакомы с понятием сезонность и активно его используют.

Так же существует множество эмпирических правил, которые изучают в ВУЗах и накапливаются с жизненным опытом. Многие правила можно четко выразить через ЕСЛИ-ТО. Это позволяет проводить математическое моделирование или Прогнозирование.

На производстве (часто) бывают системы планирования и диспетчеризации их уже можно отнести к управлению, так как
Планирование = Прогнозирование
Расширенной аналитикой и прогнозированием занимаются, в основном, крупные корпорации, имея у себя на вооружении большие вычислительные мощности, огромные массивы накопленной информации, штат специалистов и специальный софт. Этот софт доступен в интернете и, зачастую, бесплатен. Главное понимать для чего он нужен и как им пользоваться.

А если говорить о мощностях на сегодняшний день за 1000$ можно купить компьютер, который производит триллион (10^12) операций в секунду. Уже не мало. (Это я говорю о GPU например об игровых). По мне, так вполне доступно даже рядовым ИП.

Этой вычислительной мощности достаточно, чтобы в течение минуты расчитать бухгалтерский баланс, налоги, зарплату, прибыль магазина с номенклатурой 10 50 тысяч единиц. А если это сделать с разными параметрами, то мы получаем экономическое моделирование прогноз.
За сутки 24 * 60 = 1440 вариантов будущего компании

Понятно, что прогнозы и реальность часто не совпадают, потому что существуют другие игроки на рынке и множество влияющих факторов помехи. А разве мы их не можем учитывать? Вписать в векторы состояний?

И делать это как можно чаще. Получать оперативно обратную связь. По факту мы едем по серпантину с громадной скоростью медленно моргая глазами.

Где в ваших АСу механизмы воздействия? (Прямая связь)

Если у машины нет руля и тормоза далеко вы не уедете. Допустим, что роботов мы не будем внедрять в магазин или на фабрику.

Насколько корректно и удобно ваша система отображает необходимую информацию? Желательно адекватную текущему контексту. Ввод информации удобен?

Насколько быстро и качественно ваша АСу перестраивается под ситуацию, изменения законодательства, форс-мажорные обстоятельства, мировую политику, смену/добавление оборудования? Насколько устойчива ваша система к подобным воздействиям? Насколько она управляема?

Обычно кибернетическую систему перестраивают инженеры-программисты и(или) закладывают на будущее (прогнозируют) возможные варианты алгоритмов.
Кибер-система, которая перестраивается сама (желательно быстрее/эффективнее программистов) называется ИИ.
Что она перестраивает?

Правильно. Алгоритмы, функции управления для достижения целей. Да и сами цели она ставит самостоятельно.

Как она это делает сама? Это уже разговор о том, что такое Интеллект. И, как вы уже поняли,
Управление процесс интеллектуальный
Реакция на ситуацию, особенно если система прогнозирования ошиблась по тем или иным причинам (например по причинам ее отсутствия), должна быть максимально быстрая. Иначе, наехав на кочку, вы можете оказаться в кювете. В терминах управления это Катастрофа.

Насколько быстро работает ваша АСу? Какова ее Мощность?

Конечно, такую ситуацию (катастрофу) лучше всего избежать, спрогнозировав ее или получив вовремя (заранее) обратную связь. Так же не мешало бы иметь набор разнообразных алгоритмов/механизмов/приемов, которые можно будет использовать в той или иной кризисной ситуации.
Событие Прогноз Реакция Цель Подстройка Алгоритм

Грамотное применение всех вышеописанных функций повышает Точность управления, делает управление ювелирным искусством. Искусством для интеллекта.
Эффективное управление это переход от рефлексии к прогнозированию
А вашим АСу слабо?
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru