Общие типы и интерфейсы неплохи. Ну например: стандартная спецификация сигналов с верхней и нижней границей и единицей измерения (opc ua di) — вот у тебя и возможность цеплять скаду и hmi полуавтоматически.
Или стандартные типы представления автоматов через объекты для состояний и переходов (opc ua ns0 или packml) — можно использовать для мониторинга и расчета oee.
Или стандартные параметры сенсоров (opc ua di и pa dim), например серийные номера устройств итд.
Есть plcopen companion. Через него можно, в теории, браузить и менять логику в плк через стандартный интерфейс...
Плюс во многих companion specs предусматриваются методы, например управление переходами между состояниями автомата PackML.
Применение OPC UA просто шире, чем цикличные ПЛК.
и еще, тут лекции часто ведутся не по одной книге как в часто штатах или Англии (где даже слайды стандартные по книге), а по нескольким книгам и/или пэйперам. Это заставляет студентов читать разные книги и сравнивать источники.
Ну тут первые 2-3 семестра основы математики (анализ, линейная алгебра, дискретная математика, теория вероятности, мат. логика и игры, основы нумерики) являются общими лекциями для информатиков, математиков и физиков (+ учителя). Соответственно поблажек там нет, учат доказывать, разбираться в нотации итд. После второго года можно выбирать специализацию в том числе и в теорию (advanced alogirhtms, complexity beyond NP, parameterized algotihms, automata theory and logic, formal verification etc.). Заставляют сохранять некий «микс» между теорией и практикой, но специализаций очень много — практически по числу кафедр.
Очень хороший пример про метод эллипсоидов vs. simplex. Это один из примеров, где классическая теория сложности перестает помогать. Просто никто пока не понимает, почему большинство задач быстро решаются алгоритмами, которые имеют экспоненциальную асимптотическую сложность. Другой пример из статьи — SAT солверы, которые уже сейчас стали де-факто симплекс алгоритмом для NP-полных задач.
По-моему нужно уходить от worst-case и идти дальше к анализу и классификации структур проблем, как например парметеризированая сложность.
Общие типы и интерфейсы неплохи. Ну например: стандартная спецификация сигналов с верхней и нижней границей и единицей измерения (opc ua di) — вот у тебя и возможность цеплять скаду и hmi полуавтоматически.
Или стандартные типы представления автоматов через объекты для состояний и переходов (opc ua ns0 или packml) — можно использовать для мониторинга и расчета oee.
Или стандартные параметры сенсоров (opc ua di и pa dim), например серийные номера устройств итд.
Есть plcopen companion. Через него можно, в теории, браузить и менять логику в плк через стандартный интерфейс...
Плюс во многих companion specs предусматриваются методы, например управление переходами между состояниями автомата PackML.
Применение OPC UA просто шире, чем цикличные ПЛК.
ActiveSync для Win 10 работает — https://support.microsoft.com/en-us/help/931937/description-of-windows-mobile-device-center
P.S.: Хорошая книга по model checking'у (одна из ветвей верификации): mitpress.mit.edu/books/principles-model-checking
это копия клавиатуры от thinkpad
www.msg-praxisbedarf.de/%24WS/msg/websale8_shop-msg/produkte/medien/bilder/normal/44597_02.jpg
вот их главный кокурент — запускают змея с турбинами
По-моему нужно уходить от worst-case и идти дальше к анализу и классификации структур проблем, как например парметеризированая сложность.