Способ анализа нарушений функций встроенной системы, соответствующий компьютерный программный продукт и устройство анализа

Группа изобретений относится к способу и устройству анализа нарушений функций встроенной системы, машиночитаемому носителю, содержащим программу для реализации способа. Для осуществления способа в фазе моделирования этой системы определяют набор образующих ее ресурсов, для каждого из которых определяют набор сервисов, обеспечиваемых или используемых указанным ресурсом, определяют для каждого ресурса и для каждого сервиса набор статусов для характеристики их рабочего состояния или качества обслуживания, определяют правила для получения или присвоения вышеуказанных статусов. В фазе анализа конфигурируют анализ, содержащий выбор базового события, называемого маркированным базовым событием, анализируют правила для получения и определения набора базовых событий и условий для возникновения указанных событий, ведущих к возникновению маркированного базового события, и ассоциируют по меньшей мере часть базовых событий с нарушениями функций встроенной системы. Устройство содержит компьютер, содержащий процессор и запоминающее устройство, содержащее инструкции, при выполнении которых осуществляются этапы вышеуказанного способа. Обеспечивается упрощение анализа нарушений функций встроенной системы без необходимости специальной адаптации к конкретной области анализа. 3 н. и 8 з.п. ф-лы, 3 ил.

 

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

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

В частности, понятие «нарушений функций» соответствует одному из элементов, выбранному из группы, содержащей: дефект, злонамеренное действие, отказ или неисправное состояние.

Термин «дефект» обозначает аномалию в работе встроенной системы или одного из ее компонентов.

Термин «злонамеренное действие» обозначает любое вмешательство во встроенную систему или в один из ее компонентов с целью нанесения ущерба нормальной работе системы или одного из ее компонентов.

Термин «отказ» обозначает влияние, оказываемое одним или несколькими дефектами и/или одним или несколькими злонамеренными действиями на работу встроенной системы или одного из ее компонентов.

Термин «неисправное состояние» обозначает критический отказ, т.е. отказ, вызывающий критические, угрожающие последствия для работы встроенной системы в целом или одного из ее компонентов.

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

Термин «операционное предупреждение» обозначает любое текстовое, голосовое или иное сообщение, имеющее целью известить оператора, использующего встроенную систему, о нарушении функций, произошедшем в этой системе или в одном из ее компонентов. Такое сообщение генерирует, например, система аварийной сигнализации, ассоциированная с рассматриваемой встроенной системой.

Согласно известному способу анализ нарушения функций встроенной системы, и в частности, системы авионики, осуществляют на основе анализа разных областей таких нарушений функций.

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

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

Анализ нарушений функций на основе по меньшей мере некоторых из перечисленных выше областей часто производят с использованием так называемых способов рассуждений на основе моделей.

Эти способы содержат описание анализируемой системы в виде формальной модели, и затем автоматизированный анализ системы с использованием этой формальной модели.

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

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

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

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

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

Поэтому, настоящее изобретение относится к способу анализа нарушений функций встроенной системы, содержащему фазу моделирования этой системы и фазу анализа.

Фаза моделирования содержит этапы, на которых:

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

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

- для каждого статуса по меньшей мере одного ресурса или по меньшей мере одного сервиса, определяют правило принятия или присвоения этого статуса рассматриваемым ресурсом или рассматриваемым сервисом на основе статуса принятого или присвоенного по меньшей мере одним другим ресурсом или сервисом.

Фаза анализа содержит этапы, на которых:

- конфигурируют анализ, содержащий выбор базового события, именуемого маркированным базовым событием;

- осуществляют анализ правил получения и определения набора базовых событий и условий для появления указанных событий и ассоциируют по меньшей мере некоторые базовые события с нарушениями функций встроенной системы.

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

- анализ правил получения содержит реализацию алгоритма вычисления минимальных разрезов;

- условия появления базового события содержат операции логического умножения, логического сложения и логического отрицания между разнообразными базовыми событиями;

- этап конфигурирования дополнительно содержит ассоциирование по меньшей мере с одним базовым событием числовой величины, соответствующей вероятности появления этого базового события;

- этап определения набора базовых событий и условий появления этих событий дополнительно содержит вычисление вероятности возникновения маркированного базового события;

- этап конфигурирования дополнительно содержит ассоциирование по меньшей мере с одним маркированным базовым событием числовой величины, соответствующей максимальной приемлемой вероятности появления этого маркированного базового события;

- этап определения набора базовых событий и условий возникновения этих событий дополнительно содержит сравнение максимальной приемлемой вероятности возникновения маркированного базового события с вычисленной вероятностью возникновения этого маркированного базового события;

- этап конфигурирования выполняют на основе области анализа нарушений функций встроенной системы, каждую область выбирают из группы, содержащей: область диагностического анализа, позволяющую идентифицировать причину появления сообщения об ошибке во встроенной системе; область анализа эксплуатационной безопасности, позволяющую проанализировать риски возникновения состояний неисправности; область анализа обеспечения безопасности, позволяющую проанализировать последствия злонамеренных действий; и область анализа операционных предупреждений, позволяющую определить предупреждающие сообщения, указывающие на наличие одного или более нарушений функций встроенной системы;

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

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

Настоящее изобретение относится также к устройству для анализа нарушений функций встроенной системы, реализующему описанный выше способ анализа.

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

- Фиг. 1 представляет упрощенную схему устройства для анализа согласно настоящему изобретению, это устройство для анализа осуществляет способ анализа согласно настоящему изобретению, позволяющий анализировать нарушения функций встроенной системы;

- Фиг. 2 представляет упрощенную схему встроенной системы согласно Фиг. 1; и

- Фиг. 3 представляет логическую схему способа анализа согласно Фиг. 1.

Устройство 10 для анализа, показанное на Фиг. 1, позволяет анализировать нарушения функций встроенной системы 12, более подробно показанной на Фиг. 2.

Термин «нарушение функций» обозначает какое-либо событие, произошедшее во встроенной системе или в одном из ее компонентов и препятствующее нормальной работе системы или одного из этих компонентов.

В частности, понятие нарушений функций соответствует одному из элементов, выбранному из группы, содержащей: дефект, злонамеренное действие, отказ или неисправное состояние.

Встроенная система 12 представляет собой, например, систему авионики на самолете или другом воздушном судне, такую как система отопления.

Встроенная система 12 содержит несколько аппаратных и/или программных компонентов. Каждый из этих компонентов предназначен для выполнения заданной функции во время работы системы 12.

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

В примере, показанном на Фиг. 2, встроенная система 12 содержит источник 21 питания, нагреватель 22, систему 23 обслуживания и систему 24 сигнализации в полете.

Согласно этому примеру система 23 обслуживания и система 24 сигнализации в полете могут быть использованы другими встроенными системами, которые не показаны на Фиг. 2 и не будут рассмотрены позднее.

Источник 21 питания служит для подачи электрического тока к нагревателю 22.

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

Нагреватель 22 далее способен генерировать сообщения об ошибке, когда подача тепла невозможна. Это сообщение предназначено для передачи в систему 23 обслуживания и в систему 24 сигнализации в полете.

Каждая система - и система 23 обслуживания, и система 24 сигнализации в полете, способна принять сообщение об ошибке, переданное нагревателем 22.

В частности, система 23 обслуживания может, если принято такое сообщение об ошибке, генерировать сообщение обслуживания, предназначенное для оператора обслуживания.

Аналогично, система 24 сигнализации в полете может, если принято такое сообщение об ошибке, генерировать предупреждающее сообщение, предназначенное для экипажа воздушного судна.

Как показано на Фиг. 1, устройство 10 для анализа содержит модуль 31 моделирования, модуль 32 анализа и модуль 33 связи.

Модуль 31 моделирования позволяет моделировать работу встроенной системы 12 путем выполнения фазы моделирования (PM) рассматриваемого способа анализа, которая будет более подробно пояснена ниже.

Модуль 32 анализа позволяет анализировать нарушения функций системы 12 путем выполнения фазы анализа (PA) рассматриваемого способа анализа.

Модуль 33 отображения содержит, например, человеко-машинный интерфейс, позволяющий пользователю осуществлять связь с устройством 10 для анализа. Согласно хорошо известным способам такой интерфейс содержит, например, экран дисплея и средства для ввода информации, такие как клавиатура.

Это устройство 10 для анализа представляет собой, например, компьютер, содержащий также запоминающее устройство 38 и процессор 39. В этом случае модуль 31 моделирования и модуль 32 анализа имеют форму программ, хранящихся в запоминающем устройстве 38 и выполняемых процессором 39.

Способ анализа согласно настоящему изобретению будет рассмотрен далее со ссылками на Фиг. 3, где показана логическая схема этапов этого способа.

Как отмечено ранее, способ анализа согласно настоящему изобретению содержит фазу PM моделирования и фазу PA анализа.

На начальном этапе 110 фазы PM моделирования модуль 31 моделирования определяет набор ресурсов R, образующих встроенную систему 12. Каждый ресурс R_i соответствует какому-либо компоненту системы 12, как это задано заранее.

В обозначении типа “R_i”, индекс, ассоциированный с буквой “R", соответствует уникальному идентификатору соответствующего ресурса в системе 12 и изменяется от 1 до N, где N - натуральное число, обозначающее общее число ресурсов в системе 12.

Таким образом, в примере варианта, показанном на Фиг. 2, во время рассматриваемого этапа 110 модуль 31 моделирования определяет четыре ресурса R₁, R₂, R₃ и R₄, которые соответствуют источнику 21 питания, нагревателю 22, системе 23 обслуживания и системе 24 сигнализации в полете.

В ходе следующего этапа 120 модуль 31 моделирования определяет, для каждого ресурса R_i, набор сервисов S_ij, предоставляемых или используемых этим ресурсом R_i.

Каждый сервис S_ij, предоставляемый ресурсом R_i, имеет, таким образом, результатом работу этого ресурса R_i в системе 12.

Каждый сервис S_ij, используемый ресурсом R_i, представляет собой, таким образом, сервис S_nm, предоставляемый другим ресурсом R_i и используемый рассматриваемым ресурсом R_i для предоставления другого сервиса S_ik.

В обозначении типа “S_ij" первый индекс, ассоциированный с “S", обозначает идентификатор ресурса R_i, предоставляющего или использующего соответствующий сервис, а второй индекс, ассоциированный с буквой “S", соответствует уникальному идентификатору соответствующего сервиса из совокупности всех сервисов, предоставляемых или используемых ресурсом R_i. Второй индекс изменяется, например, в пределах от 1 до M, где M - натуральное число, обозначающее общее число сервисов, предоставляемых ресурсом R_i.

В примере варианта, показанном на Фиг. 2, в ходе этого этапа 120 для ресурса R₁ модуль 31 моделирования определит сервис S₁₁ как подачу электрического тока.

Для ресурса R₂, модуль 31 модулирования определяет сервис S₂₁, соответствующий потреблению этим ресурсом электрического тока, предоставляемого ресурсом R₁, сервис S₂₂, соответствующий генерированию тепла, и сервис S₂₃, соответствующий генерированию сообщения об ошибке, когда подача тепла невозможна.

Для каждого из ресурсов R₃ и R₄, модуль 31 моделирования определяет, соответственно, сервис S₃₁ и сервис S₄₁, соответствующие получению и использованию сообщения об ошибке, генерируемого ресурсом R₂.

Для ресурса R₃, модуль 31 моделирования далее определяет сервис S₃₂, соответствующий генерированию сообщения обслуживания.

Наконец, для ресурса R₄, модуль 31 моделирования далее определяет сервис S₄₂, соответствующий генерированию предупреждения.

Следует отметить, что на Фиг. 2 показаны только сервисы S₁₁, S₂₂, S₂₃, S₃₂ и S₄₂, предоставляемые ресурсами R₁ - R₄.

Следует также отметить, что список сервисов S_ij, приведенный выше в связи с ресурсами R₁ - R₄, не является исчерпывающим.

В ходе следующего этапа 130 модуль 31 моделирования определяет, для каждого ресурса R_i и для каждого сервиса S_ij, набор статусов.

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

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

В примере варианта, показанном на Фиг. 2, модуль 31 моделирования определяет, для каждого из ресурсов R₂ - R₄, набор статусов, построенный из двух статусов, а именно “OK" и "KO".

Статус “OK” определяет рабочее состояние соответствующего ресурса R₂ - R₄, в котором этот ресурс работает нормально. Статус “KO” определяет рабочее состояние соответствующего ресурса R₂ - R₄, в котором этот ресурс неисправен.

Для ресурса R₁, модуль 31 моделирования определяет набор статусов, составленный из трех статусов, а именно, “OK”, "KO” и «Перегрузка» (“Surcharged”). Статусы “OK” и “KO” характеризуют такие же рабочие состояния ресурса R₁, как и в случае ресурсов R₂ - R₄. Статус «Перегрузка» (“Surcharged”) характеризует рабочее состояние ресурса R₁, в котором этот ресурс перегружен.

Для сервисов S_ij, набор статусов, ассоциированный с каким-либо сервисом S_ij, составлен из нескольких статусов, где каждый статус из этого набора способен охарактеризовать качество обслуживания, предоставляемое рассматриваемым сервисом в некий конкретный момент времени.

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

Таким образом, в примере варианта, показанном на Фиг. 2, в ходе этапа 130 модуль 31 моделирования определяет, соответственно для сервисов S₁₁ и S₂₁, соответствующих генерированию и использованию электрического тока, набор статусов, содержащий два статуса, т.е. «Нет» (“None") и «Полный» (“Full"). Статус «Нет» (“None”) означает, что электрический ток не генерируется. Статус «Полный» (“Full”) означает, что генерирование электрического тока осуществляется нормально.

Для сервиса S₂₂, соответствующего генерированию тепла, модуль 31 моделирования определяет набор статусов, построенный из двух статусов, а именно, «Доступно» ("Available") и «Не доступно» (“Not Available"). Статус «Доступно» ("Available"), означает, что происходит генерирование тепла, и статус «Не доступно» ("Not Available") означает, что генерирование тепла не производится.

Наконец, для каждого из сервисов S₂₃, S₃₁, S₃₂, S₄₁ и S₄₂, соответствующих генерированию или получению и использованию сообщения, модуль 31 моделирования определяет набор статусов, построенный из двух статусов, а именно, «Передано» (“Sent") и «Не передано» (“Not Sent"). Статус «Передано» ("Sent") означает, что соответствующее сообщение было передано или принято, а статус «Не передано» ("Not Sent") означает, что соответствующее сообщение не было передано или принято.

В остальной части настоящего описания «базовое событие» обозначает получение или присвоение себе, ресурсом R_i или сервисом S_ij, одного из статусов, соответствующих этому ресурсу R_i или этому сервису S_ij.

Тогда можно видеть, что по меньшей мере некоторые базовые события соответствуют, например, нарушению функций системы 12 или одного из ее компонентов. Таким образом, получение или присвоение статуса “KO" ресурсом R₁ соответствует дефекту, возникшему в этом ресурсе, а получение или присвоения статуса «Перегружен» ("Surcharged") этим же ресурсом соответствует злонамеренному действию, произошедшему в отношении этого ресурса.

В ходе следующего этапа 140 модуль 31 моделирования определяет, для каждого статуса каждого ресурса R_i и каждого сервиса S_ij, по меньшей мере одно правило для получения или присвоения себе этого статуса этим ресурсом R_i или этим сервисом S_ij на основе статуса полученного или присвоенного по меньшей мере одним другим ресурсом R_i или сервисом S_ij.

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

Таким образом, в примере, показанном на Фиг. 2, модуль 31 моделирования, например, определяет правило для получения статуса «Нет» (“None”) сервисом S₁₁, согласно которому этот сервис S₁₁ получает или присваивает себе этот статус «Нет» (“None”), когда ресурс R₁ получает или присваивает статус “KO”.

В этом примере, модуль 31 моделирования определяет, например, правило для получения или присвоения себе статуса «Доступно» (“Available”) сервисом S₂₂, в соответствии с которым этот сервис S₂₂ получает или присваивает этот статус «Доступно» (“Available”), когда сервис S₂₁ получает или присваивает себе статус «Полный» (“Full”) и ресурс R₂ получает статус “OK”.

Безусловно, в примере, показанном на Фиг. 2, могут быть определены многообразные другие правила.

Этап 140 представляет собой конечный этап фазы PM моделирования. В конце этого этапа получают в результате модель системы 12.

Следует отметить, что каждый из описанных ранее этапов 110 - 140 определения может быть реализован с использованием соответствующей базы данных, хранящейся, например, в запоминающем устройстве 38 устройства 10.

Таким образом, эти базы данных, в частности, содержат список ресурсов R_i для системы 12, список сервисов S_ij для каждого из ресурсов R_i, список наборов статусов для каждого из этих ресурсов R_i и для каждого из этих сервисов S_ij и список правил для получения или присвоения по меньшей мере некоторых из этих статусов.

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

После фазы PM моделирования устройство 10 для анализа выполняет фазу PA анализа нарушений функций в системе 12 с использованием модели системы 12.

В ходе первоначального этапа 150 этой фазы модуль 32 анализа получает данные для конфигурирования анализа.

Эти данные вводит, например, пользователь посредством модуля 33 связи и делает возможным пометить базовое событие, называемое в дальнейшем маркированным базовым событием.

Маркированное событие, например, представляет собой нарушение функций встроенной системы 12 или, напротив, получение или присвоение себе ресурсом R_i статуса “OK”.

Маркированное базовое событие выбирает пользователь устройства 10 на основе области анализа нарушений функций встроенной системы 12.

Каждую область анализа выбирают из группы, содержащей:

- область диагностического анализа, позволяющую идентифицировать причину появления сообщения об ошибке встроенной системы 12;

- область анализа эксплуатационной безопасности, позволяющую анализировать риски появления состояний неисправностей;

- область анализа обеспечения безопасности, позволяющую анализировать последствия злонамеренных действий; и

- область анализа операционных предупреждений, позволяющую определить предупреждения, указывающие на одно или более нарушений функций системы 12.

Таким образом, для области диагностического анализа, маркированное базовое событие соответствует появлению сообщения об ошибке во встроенной системе 12, следующего за одним или более злонамеренными действиями в отношении системы 12 или одного из ее компонентов. Цель анализа этого маркированного базового события посредством устройства 10 состоит, таким образом, в идентификации всех причин появления такого сообщения об ошибке во встроенной системе 12. Эти причины соответствуют нарушениям функций в системе 12 и условиям для возникновения этих нарушений функций.

В примере варианта, показанном на Фиг. 2, такое маркированное базовое событие соответствует получению или приобретению статуса «Передано» ("Sent") одним из сервисов S₂₃, S₃₁, S₃₂ или S₄₁.

Для области анализа операционных предупреждений, маркированное базовое событие соответствует появлению предупреждения, в частности, передаваемого системой 24 сигнализации в полете после одного или нескольких злонамеренных действий, произведенных в отношении системы 12 или одного из ее компонентов. Цель анализа этого маркированного базового события посредством устройства 10 состоит в идентификации всех причин появления такого предупреждения. Эти причины соответствуют нарушению функций в системе 12 и условиям для возникновения этих нарушений функций.

В примере варианта, показанного на Фиг. 2, такое маркированное базовое событие соответствует получению или присвоению себе статуса «Передано» ("Sent") сервисом S₄₂.

Для области анализа эксплуатационной безопасности, маркированное базовое событие соответствует возникновению состояния неисправности. Цель анализа этого маркированного базового события посредством устройства 10 состоит в идентификации всех причин появления такого состояния неисправности и в анализе рисков возникновения такого состояния неисправности. Эти причины соответствуют нарушениям функций в системе 12 и условиям для возникновения этих нарушений функций.

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

Числовые данные первого типа соответствуют максимально приемлемой вероятности возникновения критического отказа. Эти данные, например, ассоциированы в форме числового аргумента с маркированным базовым событием, соответствующим возникновению критического отказа, и более конкретно - со статусом, полученным или приобретенным ресурсом R_i или сервисом S_ij.

Числовые данные второго типа соответствуют вероятностям возникновения нарушений функций одного из компонентов встроенной системы 12. Эти данные, например, ассоциированы с базовыми событиями, соответствующими возникновению этих нарушений функций. В частности, каждая единица этих данных ассоциирована со статусом, полученным или приобретенным ресурсом R_i или сервисом S_ij в зависимости от соответствующего базового события.

В примере варианта, показанном на Фиг. 2, такое маркированное базовое событие соответствует получению или приобретению статуса «Не доступно» ("Not Available") сервисом S₂₂.

В этом случае с этим статусом ассоциирован аргумент “1E-4", соответствующий данным этого типа, что означает, что максимально приемлемая вероятность возникновения нарушения функций нагревателя 22 равна 10^-4.

Далее аргументы “1E-5" и “1E-6", соответствующие данным второго типа, ассоциированы со статусами “KO" ресурсов R₂ и R₁, соответственно. Тогда это означает, что вероятности нарушений функций (также именуемые интенсивностями потока отказов) нагревателя 22 и источника 21 питания соответственно равны 10^-5 и 10^-6.

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

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

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

Числовые данные второго типа соответствуют вероятностям совершения злонамеренных действий в отношении встроенной системы 12. Эти данные, например, ассоциированы с базовыми событиями, соответствующими совершению этих действий. В частности, каждая единица этих данных ассоциирована со статусом, полученным или приобретенным ресурсом R_i или сервисом S_ij в зависимости от соответствующего базового события.

В примере варианта, показанном на Фиг. 2, такое маркированное базовое событие, соответствующее области анализа обеспечения безопасности представляет собой, как и в предыдущем случае, получение или приобретение статуса «Не доступно» ("Not Available") сервисом S₂₂.

В этом случае с этим статусом ассоциирован аргумент “1E-4", соответствующий данным первого типа, что означает, что максимально приемлемая вероятность возникновения состояния неисправности нагревателя 22 вследствие совершения одного или нескольких злонамеренных действий равна 10^-4.

Более того, аргумент “1E-7", соответствующий данным второго типа, назначают статусу «Перегрузка» ("Surcharged") ресурса R₂. Тогда это означает, что потенциал опасности, соответствующий злонамеренной перегрузке источника 21 питания равен 10^-7.

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

В ходе следующего этапа 160 модуль 32 анализа осуществляет анализ всех правил получения или присвоения статуса, определенных в ходе этапа 140, и определяет все причины возникновения рассматриваемого маркированного базового события. Эти причины, в частности, соответствуют возникновению одного или нескольких базовых событий, равно как и условиям для их возникновения.

В частности, в ходе этого этапа 160 модуль 32 анализа реализует известный алгоритм для вычисления минимальных разрезов. Этот алгоритм, в частности, содержит создание деревьев неисправностей на основе модели встроенной системы 12, получаемой в ходе фазы PM моделирования, и анализ этих деревьев на основе области анализа, соответствующей маркированному базовому событию.

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

Совокупность условий для возникновения различных базовых событий, например, содержит логические операции «И», «ИЛИ» и «НЕ», соответствующие логическому умножению, логическому сложению и логическому отрицанию, соответственно, различных базовых событий.

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

Таким образом, в примере, показанном на Фиг. 2, маркированное базовое событие, соответствующее получение или присвоению статуса «Передано» ("Sent") сервисом S₃₁, получают в результате следующих базовых событий и условий для их возникновения:

- базовое событие, соответствующее получению или приобретению статуса «Перегрузка» ("Surcharged") ресурсом R₁; ИЛИ

- базовое событие, соответствующее получению или приобретению статуса “KO" ресурсом R₁; ИЛИ

- базовое событие, соответствующее получению или приобретению статуса “KO" ресурсом R₂.

Первое базовое событие соответствует злонамеренному действию, совершенному по отношению к ресурсу R₁, и второе и третье базовые события, составляют отказы, возникающие в ресурсе R₁ и ресурсе R₂, соответственно.

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

Таким образом, в примере, показанном на Фиг. 2, маркированное базовое событие, соответствующее получение или присвоению статуса «Передано» ("Sent") сервисом S₄₂, получают в результате следующих базовых событий и условий для их возникновения:

- базовое событие, соответствующее получению или приобретению статуса «Перегрузка» ("Surcharged") ресурсом R₁; ИЛИ

- базовое событие, соответствующее получению или приобретению статуса “KO" ресурсом R₁; ИЛИ

- базовое событие, соответствующее получению или приобретению статуса “KO" ресурсом R₂.

Как и в предшествующем случае, первое базовое событие соответствует злонамеренному действию, совершенному по отношению к ресурсу R₁, и второе и третье базовые события, составляют отказы, возникающие в ресурсе R₁ и ресурсе R₂, соответственно.

Для области анализа эксплуатационной безопасности, найденные базовые события и условия для их возникновения позволяют идентифицировать причины появления состояния неисправности.

Для этой области, модель анализа далее вычисляет максимальную вероятность достижения состояния неисправности и сравнивает эту вычисленную им вероятность с максимальной приемлемой вероятностью возникновения состояния неисправности.

Таким образом, в примере, показанном на Фиг. 2, маркированное базовое событие, соответствующее получению или присвоению себе статуса «Не доступно» ("Not Available") сервисом S₂₂, получают в результате базового события, соответствующего получению или присвоению статуса “KO" ресурсом R₁ с максимальной вероятностью, равной 10^-5, что ниже максимально приемлемой вероятности возникновения этого маркированного базового события, которая была задана равной 10^-4.

Базовое состояние, соответствующее получению или присвоению себе статуса “KO" ресурсом R₁, соответствует отказу, произошедшему в этом ресурсе R₁.

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

Для этой области модуль 32 анализа далее вычисляет максимальную вероятность появления состояния неисправности вслед за найденным злонамеренным действием (ями) и сравнивает эту вычисленную вероятность с максимальной приемлемой вероятностью совершения этого действия.

Таким образом, в примере, показанном на Фиг. 2, маркированное базовое событие, соответствующее получению или присвоению себе статуса «Не доступно» ("Not Available") сервисом S₂₂, получают в результате базового события, соответствующего получению или присвоению статуса «Перегрузка» (“Surcharged") ресурсом R₁ с максимальной вероятностью, равной 10^-7, что ниже максимально приемлемой вероятности возникновения этого маркированного базового события, которая была задана равной 10^-4.

Базовое событие, соответствующее получению или присвоению себе статуса «Перегрузка» (“Surcharged") ресурсом R₁, представляет собой злонамеренное действие, совершенное в отношении этого ресурса R₁.

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

По завершении этапа 160 модуль 32 анализа передает результаты, полученные на этом этапе, т.е. перечень базовых событий, условий их возникновения и, в качестве опций, вероятности возникновения маркированного базового события, пользователю, например, через модуль 33 связи.

Можно видеть, что настоящее изобретение имеет ряд преимуществ.

Действительно, фаза моделирования, осуществляемая способом анализа, не зависит от области анализа, в соответствии с которой необходимо обрабатывать нарушения функций встроенной системы.

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

Фаза анализа в составе этого способа позволяет особенно просто задать нужную область анализа.

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

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

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

1. Способ анализа нарушений функций встроенной системы (12), содержащий фазу моделирования (PM) этой системы и фазу анализа (PA); при этом

фаза моделирования (PM) содержит этапы, на которых:

определяют (110, 120) набор ресурсов (R_i), образующий встроенную систему (12), и для каждого определенного ресурса (R_i) определяют набор сервисов (S_ij), обеспечиваемых или используемых указанным ресурсом (R_i);

определяют (130) для каждого ресурса (R_i) и для каждого сервиса (S_ij) набор статусов, причем каждый статус может быть получен соответствующим ресурсом (R_i) или соответствующим сервисом (S_ij) для характеристики рабочего состояния указанного ресурса (R_i) или качества обслуживания, предоставляемого указанным сервисом (S_ij), при этом получение ресурсом (R_i) или сервисом (S_ij) одного из статусов из соответствующего набора статусов составляет базовое событие;

определяют (140) для каждого статуса по меньшей мере одного ресурса (R_i) или по меньшей мере одного сервиса (S_ij) правила для получения или присвоения указанного статуса рассматриваемым ресурсом (R_i) или рассматриваемым сервисом (S_ij) на основе статуса, полученного или присвоенного по меньшей мере одним другим ресурсом (R_i) или сервисом (S_ij); а

фаза анализа (PA) содержит этапы, на которых:

конфигурируют (150) анализ, содержащий выбор базового события, называемого маркированным базовым событием;

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

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

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

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

5. Способ по п. 4, в котором этап определения (160) набора базовых событий и условий для возникновения указанных базовых событий дополнительно содержит подэтап, на котором вычисляют вероятность возникновения маркированного базового события.

6. Способ по п. 1, в котором этап конфигурирования (150) дополнительно содержит подэтап, на котором ассоциируют с указанным маркированным базовым событием числовую величину, соответствующую максимально приемлемой вероятности возникновения указанного маркированного базового события.

7. Способ по п. 5, в котором этап определения (160) набора базовых событий и условий для возникновения указанных событий дополнительно содержит подэтап, на котором сравнивают максимально приемлемую вероятность появления маркированного базового события с вычисленной вероятностью возникновения маркированного базового события.

8. Способ по п. 1, в котором этап конфигурирования (150) осуществляется на основе области анализа нарушений функций во встроенной системе (12), причем каждую указанную область выбирают из группы, содержащей:

область диагностического анализа, позволяющую идентифицировать причину появления сообщения об ошибке во встроенной системе (12);

область анализа эксплуатационной безопасности, позволяющую анализировать риски возникновения состояний неисправности;

область анализа обеспечения безопасности, позволяющую анализировать последствия совершения злонамеренных действий; и

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

9. Способ по п. 1, в котором каждое маркированное базовое событие соответствует одному из элементов, выбранному из группы, содержащей:

появление сообщения об ошибке;

возникновение состояния неисправности; и

появление предупреждения.

10. Машиночитаемый носитель данных, хранящий компьютерный программный продукт, содержащий программные команды, вызывающие при их исполнении компьютерным оборудованием выполнение способа по любому из пп. 1-9.

11. Устройство (10) анализа нарушений функций во встроенной системе (12), содержащее: модуль (31) моделирования, модуль 32 анализа и модуль 33 связи, выполненные с возможностью осуществления способа анализа по любому из пп. 1-9.