The 7 references with contexts in paper A. Kolchin F., N. Mikheev V., А. Колчин Ф., Н. Михеев В. (2016) “АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМЫ, СВЯЗАННОЙ С БЕЗОПАСНОСТЬЮ // ARCHITECTURE OF SAFETY RELATED SYSTEM SOFTWARE” / spz:neicon:sustain:y:2015:i:1:p:75-87

1
ГОСТ Р МЭК 61508–2012 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Части 1 – 7.
Total in-text references: 5
  1. In-text reference with the coordinate start=1784
    Prefix
    Одним из подходов, объединяющих методы оценки надежности как для аппаратных средств, так и для программного обеспечения, является методология функциональной безопасности, представленная в ГОСТ Р МЭК 61508
    Exact
    [1]
    Suffix
    . Данный стандарт охватывает разработку относительно простых систем, обеспечивающих выполнение, как правило, одной функции – функции безопасности – и называющихся «системами, связанными с безопасностью».

  2. In-text reference with the coordinate start=3887
    Prefix
    Входные/выходные устройства и вспомогательные средства: а) датчики и прочие устройства ввода; б) исполнительные устройства и прочие устройства вывода; в) источники питания, средства коммуникации и др. 1.2. Требования к системе Согласно модели жизненного цикла системы, связанной с безопасностью
    Exact
    [1]
    Suffix
    , к началу процесса создания ее архитектуры программного обеспечения разработан уже большой объем документов, описывающих управляемое оборудование, функции безопасности и различные требования к системе программного обеспечения, выявленные на предыдущих стадиях.

  3. In-text reference with the coordinate start=6935
    Prefix
    Взаимодействие с пользователем минимально, работа в основном автономна. 1.3. Требования к архитектуре программного обеспечения Можно выделить три группы требований к архитектуре программного обеспечения
    Exact
    [1]
    Suffix
    : 1. Требования уровня полноты безопасности к архитектуре программного обеспечения и инструментам проектирования. 2. Общие требования со стороны системы, связанной с безопасностью. Данные требования прямо или косвенно могут влиять на архитектуру. 3.

  4. In-text reference with the coordinate start=7482
    Prefix
    Первая группа включает в себя различные требования, например, к документальному оформлению процесса, прослеживаемости и т.п. Также данная группа включает методы разработки архитектуры, требуемые 1 В
    Exact
    [1]
    Suffix
    нет каких-либо ограничений на размеры или сложность программ, однако с повышением требований к отказоустойчивости к системе, усложняются методы обеспечения ее уровней полноты безопасности, поэтому рекомендуется реализовывать более простые (как вариант – реализовывать частично) функции безопасности на отдельной системе, связанной с безопасностью. для конкретного применения в зависимости от уров

  5. In-text reference with the coordinate start=22124
    Prefix
    В работе представлены результаты сравнения применимых структур и стилей, которые предлагается использовать при разработке программного обеспечения, удовлетворяющего требованиям функциональной безопасности
    Exact
    [1]
    Suffix
    . Использование рассмотренного подхода позволит повысить корректность и эффективность разработки программного обеспечения систем, связанных с безопасностью, на этапе выбора архитектуры программного обеспечения.

2
Philip J. Koopman Jr., Design constraints on embedded real time control systems. Systems Design & Networks Conference, (1990).
Total in-text references: 1
  1. In-text reference with the coordinate start=8144
    Prefix
    Вторая группа включает в себя ограничения по ресурсам, размерам, интерфейсам ввода-вывода и т. д., которые зависят от конкретной задачи. Однако можно утверждать, что данные требования в основном ограничивают ресурсоемкость архитектуры
    Exact
    [2]
    Suffix
    . Источником третьей группы может быть вид разработки, например, если необходимо надстроить разрабатываемую систему над имеющейся основой, предоставляемой производителем контроллера. Кроме того, они могут быть связаны с особенностями аппаратного обеспечения, когда выбранный контроллер реализует специальную технологию, оптимизированную для определенной архитектуры программного обеспечения.

3
Douglas Densmore, Roberto Passerone, Alberto Sangiovanni-Vincentelli, A Platform-Based Taxonomy for ESL Design. IEEE Software.
Total in-text references: 2
  1. In-text reference with the coordinate start=8620
    Prefix
    Кроме того, они могут быть связаны с особенностями аппаратного обеспечения, когда выбранный контроллер реализует специальную технологию, оптимизированную для определенной архитектуры программного обеспечения. Проектирование программного обеспечения обычно ведется тремя разными способами
    Exact
    [3]
    Suffix
    : а) Разработка нового программного обеспечения на основе спецификации. б) Разработка программного обеспечения для интеграции в существующую платформу. Данный процесс больше ориентирован не на проектирование и разработку программного обеспечения, а на отображение требуемого функционала на заданный программный каркас (framework). в) Доработка существующего программного обеспечения.

  2. In-text reference with the coordinate start=17198
    Prefix
    На сегодняшний день нет какого-то единого списка подобных шаблонов, или даже единого мнения по поводу того, насколько они должны быть абстрактными, однако в рамках задачи, рассматриваемой в настоящей работе, можно выделить следующий набор шаблонов (или стилей) архитектур1
    Exact
    [3]
    Suffix
    : 1. Конвейеры и фильтры (pipes and filters). 2. Абстракция данных и объектно-ориентированная организация (Data Abstraction and Object-Oriented Organization). 3. Событийная система, неявный вызов (Event-based, Implicit Invocation). 4.

4
David Stonier-Gibson, Understanding embedded microcontroller multitasking RTOS alternatives.
Total in-text references: 1
  1. In-text reference with the coordinate start=10804
    Prefix
    Выполненный анализ показал, что архитектуру программного обеспечения систем, связанных с безопасностью, можно представить и описать с помощью следующих трех инвариантных составных частей (которые иногда называют шаблонами архитектуры): 1. Структура программы
    Exact
    [4]
    Suffix
    описывает способы организации базовых функций, таких как управление памятью, управление потоками и т.п. 2. Стиль архитектуры [5] описывает способ логического деления системы, которое реализуется на основе структуры системы. 3.

5
David Garlan, Mary Shaw, An Introduction to Software Architecture.
Total in-text references: 1
  1. In-text reference with the coordinate start=10932
    Prefix
    Выполненный анализ показал, что архитектуру программного обеспечения систем, связанных с безопасностью, можно представить и описать с помощью следующих трех инвариантных составных частей (которые иногда называют шаблонами архитектуры): 1. Структура программы [4] описывает способы организации базовых функций, таких как управление памятью, управление потоками и т.п. 2. Стиль архитектуры
    Exact
    [5]
    Suffix
    описывает способ логического деления системы, которое реализуется на основе структуры системы. 3. Решение задачи, описываемое в терминах структуры программы и стиля архитектуры. Таким образом, в настоящей статье под архитектурой программного обеспечения систем, связанных с безопасностью, будем понимать набор представлений и описаний: - структуры программы; - стиля архитектуры; Таблица 3.

6
http://en.wikipedia.org/wiki/Embedded_ system#Embedded_software_architecturs
Total in-text references: 1
  1. In-text reference with the coordinate start=14394
    Prefix
    Структура программы Системы, связанные с безопасностью, по сути, являются подклассом встраиваемых систем, поэтому варианты организации структуры программы довольно схожи с вариантами, применяемыми в обычных встраиваемых системах. Для реализации программного обеспечения систем, связанных с безопасностью, можно использовать следующие структуры программ
    Exact
    [6]
    Suffix
    : 1. Простой цикл управления (simple control loop). 2. Система, управляемая прерываниями (interrupt controlled system). 3. Совместная или кооперативная многозадачность (cooperative multitasking). 4. Вытесняющая многозадачность (preemptive multitasking) или многопоточность (multi-threading). 5.

7
Mary Shaw (1995), Comparing Architectural Design Styles. IEEE Software.
Total in-text references: 1
  1. In-text reference with the coordinate start=17692
    Prefix
    В таблице 3 рассмотрены преимущества и недостатки перечисленных стилей программ при создании систем, связанных с безопасностью. В работе для сравнения стилей архитектуры были использованы следующие критерии качества
    Exact
    [7]
    Suffix
    : 1. Поддерживаемость – степень простоты внесения изменений (добавление новых обработчиков, удаление старых, модификация существующих и т.п.). 2. Повторная используемость – степень применимости составных частей существующих программ при создании новых. 1 Безусловно, возможны как и комбинации указанных архитектур, так и совершенно новые 3.