Поиск-ориентированная системная инженерия и другая пост-моделеориентированная жизнь

[ailev]

Что будет с системной инженерией дальше?

1. Классическая системная инженерия, в которой чертежи и диаграммы даны "картинками" (то есть недоформализованы, компьютер отрабатывает их как наборы линий, а не наделённые смыслом модели), знание оформляется главным образом документацией, текстами с картинками. Расчёты даны в виде бумажных описаний,

Comments

[vit_r]

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

Судя по реалиям софтверного инжениринга, все эти игры с моделями живут отдельно от реальности.

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

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

[ailev]

Я с удивлением выяснил, что инженеры не вполне понимают осознанно, что же именно они делают. Поэтому и инструменты они не очень понимают, как использовать. Но если компоненты и соединения обсчитывать в Modelica, а модули с их интерфейсами прописывать в SysML и следить за тем, чтобы компоненты и модули соответствовали друг другу, то даже с SysML и Modelica всё получится. Но лучше бы, конечно, иметь другие инструменты для всего этого, но эти другие инструменты нужно а) придумать и б) научить людей инженерии так, чтобы у них был шанс этими инструментами воспользоваться

[vit_r]

Проблема в том, что инструменты определяют стиль мышления. Рисование прямоугольничков с мелким текстом приводит к его туннелизации. В софте я видел примеры на самом деле фатальные

[ailev]

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

[don_corleonov]

Довольно регулярно сталкиваюсь с проблемой "несквозного" проектирования чего-нибудь инженерного (электроника, строительство), и пытаюсь понять, а удалось ли САПРовщикам вообще продвинуться хоть как-то от уровня PCAD? В нем хоть как-то связывались принципиальная и монтажная схема и, с оговорками, моделирование.

[ailev]

Кое-где это удаётся, но не полностью. Так Autodesk PLANT 3D и P&ID (для process plant) удобно связаны, но без расчётов. Но вот уже Inventor к этому не пришивается ни с какого боку, и поэтому принципиальную схему там "мёртвую" рисуют в AutoCAD, расчёты вообще ведутся где-то сбоку.

Собственно, это хорошая задачка для стартапа ;-)

[don_corleonov]

Мой первый "внятный" стартап был как раз по теме моделирования/проектирования топологий микросхем. Там тоже много разных сущностей, причем без итераций, когда из кремния обратно вытягивается реальная схема и опять моделируется, не обойтись. Это так, к слову.

Ну да ладно, микроэлектроника наука мутная и трудная :) Как посмотришь на самые банальные задачи типа КД на строительство. Все, пипец. Проект поделен на ОВ, АР и прочие ВК, между ними косячь как хошь. САПР - просто замена кульмана и всё. Недавно читал про страшно-престрашный пакет, который умеет генерить по чертежам деталировку каркасного дома. Задача не то, чтобы примитивная, но и не ядреная физика.

Стартапам работы хватит, да. И системным инженеГрам тоже :)

[formerchild]

Ну да, ТК где-то здесь - "синтез" архитектурного решения как решения уравнения в морфизмах. (Ко)предельные решения как типовые, базовые, минимальные, оптимальные и т.д.

Более того, ТК это базовый, объединяющий способ синтеза, т.е. синтез различных способов синтеза. А значит находится в прямой зависимости от _любых_ успехов в этой области.

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