Симултрек = архитектурный фреймворк (обеспечивающих) предприятий системной инженерии

СУТИ (система управления технической информацией, integrated repository, engineering content management system) -- программно-аппаратный комплекс , обеспечивающий учет информации о целевой системе (модель продукта), ее жизненном цикле (модель жизненного цикла), а также об обеспечивающих системах (организационная модель). Информация -- это набор фактов. Учет информации -- процедуры сбора и хранения фактов, а также процессов доступа к фактам. Модель -- информация (набор фактов), используемая стейкхолдерами для удовлетворения своих интересов. Стейкхолдер (stakeholder) -- физическое лицо или организация, которые имеют право, долю, притязания или выгоду в системе или обладанию системой характеристиками, которые удовлетворяют их нуждам и ожиданиям (individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations). Интерес (concern) -- конкретные озабоченности, которые имеет стейкхолдер по поводу каких-то аспектов целевой или обеспечивающих систем. СУТИ организован так, чтобы поддерживать Симултрек. Изначально слово "симултрек" (simultrack) использовалось в спортивныхпередачах, чтобы описать трансляцию одновременно со многих камер,установленных вокруг спортивной арены -- так, чтобы режиссер всегда могвыбрать самый лучший ракурс (в современных системах спортивныхтрансляций выбирать между камерами могут и сами зрители). Дальше это слово стало использоваться в тех случаях, когда нужно отразить учетмножества точек зрения на один и тот же объект. Симултрек (architectural framework, viewpoint library) -- это набор вьюпойнтов ("точек зрения") на связанные модели целевой системы и обеспечивающих систем. Симултрек тем самым представляет собой архитектурный фреймворк предприятий системной инженерии (обеспечивающих систем), предоставляющих ресурсы для осуществления жизненного цикла целевой системы. Вьюпойнт (viewpoint) -- это "точка зрения", набор нотаций и инструментальных средств (приложений, обеспечивающих вывод диаграмм), которые удобно представляют факты Модели, соответствующие каким-то интересам (concerns) стейкхолдера. Состав Симултрека (набор вьюпойнтов) определяет средства представления (репрезентации) следующих наборов фактов: 1. Модель продукта (целевой системы) 1.1. Модель функций -- как функциональные требования, "поведение", так и процессы (потоки жидкостей, балансы материалов, энергии и т.д.). 1.2. Модель конструкции (физических объектов). 1.3. Архитектурное описание (связывающее функции и конструкцию). 2. Модель проекта (обеспечивающих предприятий) 2.1. Модель жизненного цикла -- процессы системной инженерии, выполняемые обеспечивающими системами. Выполнение этих процессов и является жизненным циклом целевой системы (продукта). 2.2. Модель организации жизненного цикла (Конструкционные модели DEMO: роли акторов, транзакции, координационные факты, продукционные факты. Модели функции: целевые показатели). 2.3. Модель ресурсов жизненного цикла (людей и оборудования, необходимых для осуществления жизненного цикла целевой системы, даталогические модели для коммуникации, состав программ и оборудования СУТИ и т.д.). Каждый из вьюпойнтов подразумевает представление (репрезентацию) трех типов фактов: -- знания, выражаемые фактами (отношениями) типа "может быть" и "может иметь", подразумевающие, что конкретное значение для конкретного объекта будет подставлено. -- требования, выражаемые фактами (отношениями) типа "должен быть" и "должен иметь". -- о конкретных вещах, идеальных (дизайны) или реальных (оборудование, сооружения, проекты), выражаемых фактами (отношениями) типа "является" и "имеет". Интегрированные данные Симултрека (integrated dataset) -- общий набор учтенных связанных фактов различных моделей, соответствующих вьюпойнтам Симултрека и находящихся в СУТИ предприятий, предоставляющих ресурсы жизненного цикла. * * * Конечно, все это еще чистить и чистить, но лиха беда начало. Стандартные Enterprise Architecture Frameworks не подходят, а нужно было сделать что-то в этом роде. Еще требовалось привязать все модели к стандартному делению на Facility Model (Product Model) и Project Model, и при этом учесть труды Dietz по архитектурным фреймворкам и организационной онтологии, а также жестко указать на использование онтологии фактов. Пока удалось даже обойти сколькзий вопрос про "расширенное предприятие", но не удалось обойтись без понятия "учет" (которое мало кем понимается, но у Диеца это вообще раскрывается через "ведение банков фактов о состоянии мира координации и мира производства", так что можно будет пробовать прорваться).