Декабрь 2015 скачать эту статью как PDF

Обзор

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

Седьмая лекция Тим 2015 в Карлтонском университете состоялась 29 октября и был представлен Крис Hobbs, консультант по безопасности программного обеспечения в QNX программных систем. Лекция охватывает меняющийся характер программного обеспечения безопасности критически важных за последние 20 лет, включая краткое обсуждение стандартов, которые направляют развитие в медицинских, промышленных и автомобильных областях. Хоббс также продемонстрировали некоторые из инструментов, рекомендованных в стандартах безопасности и которые используются при проверке.

Резюме

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

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

Хоббс предупредил, что «система не может быть безопасным. Это вопрос достаточно безопасно ли это». И определить, является ли система «достаточно безопасной» требует понимания риска и безопасности и контекст, в котором будет использоваться конкретная система. Международная организация по стандартизации (ИСО, 2011) определяет риск как «сочетание вероятности причинения вреда и тяжести вреда», в то время как неразумных риск является «риск, признаны неприемлемыми в определенном контексте». В отличие от безопасности описывается как «отсутствие необоснованного риска согласно действительным общественных моральных понятий».

Итак как мы можем проверить, является ли конкретная система достаточно безопасным? Программное обеспечение международного тестирования стандарт-ISO/IEC/IEEE 29119 (2013) – утверждает, что из-за сложности систем и программного обеспечения невозможно проверить систему исчерпывающим образом; тестирование становится деятельность выборки. Даже динамическое тестирование является «недостаточным для обеспечения разумных гарантий того, что программное обеспечение будет функционировать как».

В частности цель тестирования программного обеспечения является оценить доступность и надежность системы. Доступность спрашивает: «Система дает ответ?», в то время как надежность спрашивает: «Является ли ответ правильным?» Хотя оба эти аспекта имеют важное значение, в зависимости от системы и ее функционального контекста, доступность и надежность может быть более важным для безопасности. Например это безопаснее для некоторых систем определить, что, если надежный ответ не может быть дано, то никакого ответа необходимо. Однако в других контекстах, даже в некоторой степени недостоверной информации может быть более безопасным, чем никакой информации вообще. К сожалению когда дело доходит до тестирования, есть много больше методов для оценки доступности, чем надежность. Разработчики должны тщательно рассмотреть этот баланс и определить, какой аспект является более важным для безопасности их системы – и проектные решения соответственно.

Учитывая, что мы не можем создать абсолютно безопасные системы, мы должны как-то решить, что является достаточно безопасным. Хоббс описаны три метода, которые обычно используются для оценки риска и решить, является ли данная система является достаточно безопасным:

  1. Столь же низко как разумно практический (ТЕРПИМЫЕ): общество определяет, какие уровни риска являются неприемлемыми и широко приемлемыми и между ними является областью, где финансовые решения (часто на основе ценности человеческой жизни) будет влиять на усилия по смягчению последствий рисков.
  2. Globalement au moins Аусси Бон (GAMAB): Новая система должна предложить глобальный уровень риска не хуже, чем от существующей эквивалентной системы.
  3. Минимальная эндогенные смертность (MEM): риск оценивается на основе базовой вероятности смерти от несчастного случая, и новые системы не должны добавить больше, чем определенный уровень риска для этой базовой суммы, которая зависит от страны/рынка.

В любом случае разработка программного обеспечения системы к приемлемой безопасности требует пристального внимания к риску и некоторую дополнительную работу. Хоббс оценкам что развитие безопасности критический стандарт требует только 10% дополнительных усилий над «профессиональное развитие» стандарт, но он отмечает, что многие компании на самом деле разработкой программного обеспечения гораздо ниже стандарта, что делает дополнительные расходы, связанные с разработкой безопасного программного обеспечения кажутся высокими. Для компаний, уже используется для разработки коммерческого класса программного обеспечения Разработка программного обеспечения безопасности критически важных не требует много дополнительных усилий.

Однако помимо дополнительных затрат времени и развития усилий, есть также процесс сертификации, который не просто. Ллойд и Рив (2009) сообщил о попытках сертификации 16 компаний и обнаружили, что, во время отбора проб, только 25% из тех попыток, которые достигли результата привели к успешной сертификации: более половины компаний не просто не завершить процесс сертификации.

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

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

Таким образом Лекция сосредоточена на следующих ключевых сообщений:

  • Почти все современные компьютеры являются встроенными устройствами.
  • Все большее число этих устройств выполняют безопасности критически важных функций.
  • Программное обеспечение для этих устройств должна быть надежной.
  • Мы больше не можем протестировать программное обеспечение, чтобы убедиться, что он работает правильно.
  • Есть много проблем с встроенными устройствами: эфемерное и трудно диагностировать ошибки, восприимчивость оборудования и отсутствие инструментов. И эти проблемы становятся хуже.
  • Безопасность в настоящее время является неотъемлемой частью безопасности.
  • Существуют международные стандарты по разработке программного обеспечения безопасности критически важных.

 


Ссылки

ISO. 2011. ISO 26262: Дорожные транспортные средства — Функциональная безопасность. Женева: Международная организация по стандартизации (
ИСО).https://www.iso.org/obp/ui/#iso:std:iso:26262: - 1:ed - 1:v1: en

ISO/IEC/IEEE. 2013. Тестирование стандарт международного программного обеспечения. Женева: Международная организация по стандартизации (ИСО) / Международной электротехнической комиссии (МЭК) / Институт электротехники и электроники инженеров (
IEEE).http://www.softwaretestingstandard.org

Ллойд, м. х. & Рив, P. Дж. 2009. IEC 61508 и IEC 61511 оценок – некоторые уроки, извлеченные. Документ, представленный на 4-й IET международной конференции по системам безопасности. Лондон: Институт машиноведения и технологии (
IET).http://dx.doi.org/10.1049/cp.2009.1540

 

Этот доклад был написан Крис Hobbs и Крис Макфи.

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
Нет голосов были поданы еще. Скажи свое слово!

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

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

Обычный текст

  • Теги HTML не разрешены.
  • Адреса электронной почты и адреса страниц включите в ссылки автоматически.
  • Строки и параграфы переносятся автоматически.