syoma

А зачем описывать большой проект автоматами состояний? Автоматы применяются там, где они нужны и решают нужную задачу с максимальной эффективностью и минимальным временем реализации алгоритма. Например, в системах управления, автоматы состояний часто реализуются как верхний уровень управления чем либо - нормальная работа, старт, стоп, авария, различные режимы. А в каждом из этих состояний уже реализуется свой алгоритм. Или наоборот, автоматы хорошо работают на очень низком уровне - например машина приема/передачи SPI, контроль/защита IGBT или как вы написали - обработка клавиш, индикация. Тогда есть, чем гордиться.

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

Если это так, то тогда я нихера не вижу смысла в этой затее.

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

Лично что я понял из презентации, что мне показали - это то, что SysML позволяет отойти от описания требований в виде текста, т.е. "Система должна обеспечивать управление самолетом одной рукой" или Visio. А вместо этого, где нужно, требования можно представить в виде автомата состояний, или событий (клиент отсылает запрос на сервер, сервер отвечает через 5мс) или Use Case (пользователь хочет сделать то-то) и еще 7-ю способами. Вроде удобно - используешь тот инструмент, который подходит в данном случае. Ну и еще возможность связи требований, но тут я вообще не понял, как при этом отследить все это дело на корректность и наполненность. Вот поэтому и ищу примеры - чтобы на пальцах показали, как оно в реальности работает и работает ли. Вот в интернете даже есть модель космического корабля (HTML версия тут) сделанного в SysML. Да вот только реально полетит ли такой корабль, спроектированный таким образом? NASA же предпочитает работать по старинке, скормив поставщикам 300-страничный документ с требованиями. И вот летают же? Разрыв между документацией и проектом, конечно же будет - так как SysML это не решает. И мало того, я не вижу здесь возможностей для гибкой методологии разработки(Agile). Т.е. придется ждать сперва пока полностью не сделается модель и только потом приступать к разработке. В общем для меня пока загадка, зачем нужен еще один костыль. В Domain-Specific многие из этих проблем снимает тот-же Matlab/Simulink + кодогенерация + тесты. Вот уж действительно полезная штука - и требования и проект генерятся из одной модели, почти 100%-ное соответствие документации проекту и отслеживание. А тут какая-то фигня.

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

Вот что делает с людьми отсутствие знакомства с продукцией фирмы WAGO.

Используйте то, что прижилось в умном доме. Z-wave например. И там есть все, что вам нужно для надежной работы. Но, конечно, стоит не копейки. Народ все чаще сейчас выбирает беспроводку, так как с кабелями та еще морока. Но это так - для будущего.

Народ, подскажите, какие есть популярные и доставаемые DIN-реечные встроенные PC с Intel процессором и Виндой? Или с монтажным китом на Дин-рейку. Желательно без вентиляторов и от нормальных вендоров и чтобы надежное было более или менее. Нужно для тестового стенда, SSD гигов на 32, HDMI, USB для мыши/клавы. Памяти, чтоб винда нормально работала. Одна особенность: желательно 2х честных 1Gb Езернета или возможность установки PCIe карточки с эзернетом, а не через USB свисток. Но это желательно, а не необходимо. Если дорого, то и без них обойдусь. Спасибо.

Вопрос к ТС - нужно ли будет потом эти все 45 линий быстро отсоединять при ремонте платы - или это один раз поставил и забыл?

Ну если бы так было, то покупали бы только дешевых китайцев, а не айфоны. У каждого есть своя ниша и ТС может легко всунуть интересную фичу в свой прибор, которой не будет у китайцев, причем это может быть что-то, что будет трудно скопировать. Например техническая поддержка на русском языке. Или надежность. Или выход на строителей. Цена здесь не является определяющим фактором - я бы купил что-то дорогое, но что выглядит надежным и проработанным. Особенно, если от этого зависит моя безопасность.

В данном случае это 100%-но зависит от разработчика. Захочет, сделает по-дубовому, что даже разряд молнии прямо в ванной будет ей пофигу. А не захочет, сделает так, что любой чих будет приводить к зависаниям. Или будет добиваться компромиссов между надежностью и ценой. Единственное, что на безопасности нельзя экономить.

Нет, на том, что поддерживает новые методы программирования Ну вы в курсе, какие.

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

Краны в виде электромагнитных клапанов сами закрываются при отсутствии электричества. У меня такие стоят и кстати дешевле шаровых, насколько я знаю. Но сразу же зададите вопрос, а что, если света нет, а нужна вода, и аккумулятор уже разрядился?