про advancing manufacturing, cyber-physical production systems, etc. —

суперплотный обзор Carl Bass (CEO of 3D design, Autodesk) по современным изменениям в воплощении (видео): http://ailev.livejournal.com/1137544.html

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

«вдогонку» — http://ailev.livejournal.com/1103473.html (видео и аудио по-

русски)

свежайшую книжку по 3D печати и 3D принтерах (на русском): http://3dplast.net/news/pervaya-kniga-o-3d

материалы свежих обзоров по ссылкам тут: http://ailev.livejournal.com/1134471.html.

тезисы по тотальной автоматизации — http://ailev.livejournal.com/1131557.html (и факультативно http://ailev.livejournal.com/1131958.html, где меньше про выход в физику – то есть меньше про роботику, но отвечается на ряд аргументов).

Что из этого вы готовы применить в ваших проектах? Сколько это будет стоить, если делать изготовление в России? Сколько бы это стоило, если бы вы это делали в Китае? в США? (сколько займёт времени заказ-изготовление-пересылка: перевести это замедление проекта в деньги с учётом рисков).

7. Определение системы: требования, архитектура, неархитектурная часть проекта

Определения и описания

Перед тем как систему воплотить, её нужно как-то определить (define). Это определение системы — основная альфа инженерного проекта, а выражается она рабочими продуктами, которые совместно называются описанием (description) системы. Конечно, есть огромное число вариаций этой терминологии (например, определение системы называют “проектом”, а описание — “проектной документацией”), тем не менее нужно понимать разницу: определение системы всегда есть, если есть система (если система никак не определена, то откуда вообще мы знаем, о какой системе мы говорим?!) — но вот описаний может не быть, если никто не потрудился задокументировать определение системы в рабочих продуктах.

Определение системы как альфа включает в себя основные подальфы (это только основные подальфы, их может быть много больше):

●Требования (определение системы как “чёрного ящика”)

●Архитектуру (важнейшие инженерные решения, определяющие систему как “прозрачный ящик”)

●Неархитектурная часть проекта (все инженерные решения, которые будут сочтены не самыми важными) — “рабочка”.

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

Часто выделяют проект/design как совокупность архитектурной и неархитектурных частей (вся архитектура — это design, но не весь design это архитектура). Часто

альфы, а описание — значком рабочего продукта. Воплощение системы удовлетворяет определению системы, а определение системы характеризует (а пока системы нет, то определяет) воплощение системы. Тематический (т.е. финансовый, физический, архитектурный и т.д.) метод (набор практик, в своей совокупности позволяющий проводить описание по какой-то тематике) описания (vewpoint) задаёт тематическую группу описаний (veiw), а каждая группа описаний имеет свой метод описаний.

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

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

Методы описаний поставляются наукой. Дисциплины, задающие виды моделей — это научные (учебные, профессиональные) дисциплины, предлагающие различные виды моделей. Модель (тут мы чаще всего будем говорить об информационной модели, а не о физической “натурной” модели) — это система M, которая может быть использована в каких-то пределах для получения знания о системе S. Модель в разы, разы и разы проще реальной системы S, она опускает неполезную для интереса стейкхолдера информацию, и предоставляет полезную.

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

●библиотечный (library) в переносном смысле слова — описанный в какой-то литературе, и на это описание можно сослаться. Иногда библиотечные методы описания называют Framework (и даже library framework) — например, TOGAF (The Open Group Architecture Framework) это “метод описания архитектуры консорциума по стандартизации The Open Group”, i* requirements framework — метод описания требований i*.

●Собственной разработки (что по факту означает необходимость проведения научной работы: изобретения каких-то абстрактных сущностей, постоения какой-то новой теории, разработки новой нотации, а затем документирования результатов этой работы).

Нужно запомнить: описаний без метода описания не существует. Если вы пишете прозой, то метод описания — “проза, жанр эссе”. Если вы описываете финансы (а хоть и финансовый баланс), то вы должны указать метод: российская система бухучёта или международная. Вы всегда явно должны давать ссылку на метод описания, по возможности его уточняя. А если используется метод описания

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

Очень часто метод описания известен неявно (например, машиностроительное предприятие будет использовать “чертежи по ЕСКД”). Но стоит этим чертежам попасть в иностранную фирму (или строительную организацию, привыкшую к “чертежам по СПДС”), и содержание этих чертежей становится уже не таким понятным. Поэтому явное указание метода описания — это хороший тон в инженерных проектах. Если вы приводите диаграммы сценариев использования (use case diagrams) для описания требований, то обязательно скажите, что это use case diagrams (а не придуманный вами самими способ задавать функциональность системы), а ещё лучше — дайте ссылку на ту книгу, из которой вы взяли конкретный использованный вами метод описания и сам вид этих диаграмм.

Нужно особо отметить, что описания — это всегда описания какой-то системы в системной иерархии (холархии). Имя описания может добавляться к имени системы через & (например, =процессор&логическая схема или -насос&инструкция по подключению).

Контроль конфигурации

Конфигурация системы — это то, из чего на какой-то момент времени состоит система. Конфигурация находится под контролем, если конфигурация определения системы соответствует конфигурации воплощения системы. Если какие-то части этих конфигураций не соответствуют друг другу, то говорят о конфигурационных коллизиях (например, если на принципиальной схеме изображено 12 насосов, а в реальной системе их стоит 11). В какой-то момент в США была отобрана лицензия атомной электростанции: из-за многочисленных модификаций оборудования чертежи перестали соответствовать реально установленному оборудованию, и эксплуатация станции в такой ситуации была признана небезопасной.

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

Для того, чтобы обеспечить контроль за конфигурацией (configuration control), используется практика управления конфигурацией (configuration management). Эта практика системноинженерного менеджмента — она занимается поддержанием целостности системы на протяжении всего жизненного цикла.

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

(bill of materials, список комплектующих).

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

(product data management — системы хранения информации проекта-design), PLM

(product life cycle management: это PDM+система управления изменениями и поддержка интерфейсов в другие информационные системы других стадий жизненного цикла — системы закупок, например), EAM (enterprise asset