Вы правы, для таких применений Modbus не лучший выбор.
Однако, несмотря на древность, если необходимо обеспечить в оборудовании считывание данных и запись настроек на небольших скоростях, я бы рекомендовал использовать именно его.
Вообще-то, желание упорядочить требования к протоколу заслуживает одобрения, я считаю.
Хотя классификации подобного рода встречались и ранее
животные делятся на:
а) принадлежащих Императору,
б) набальзамированных,
в) прирученных,
г) молочных поросят,
д) сирен,
е) сказочных,
ж) бродячих собак,
з) включённых в эту классификацию,
и) бегающих как сумасшедшие,
к) бесчисленных,
л) нарисованных тончайшей кистью из верблюжьей шерсти,
м) прочих,
н) разбивших цветочную вазу,
о) похожих издали на мух.
Видите ли, формат пакета - технический компромисс, получающийся в результате анализа требований к протоколу, как части системы, обеспечивающей решение какой-то задачи. Поэтому начинать надо с другого.
Во-первых, посмотреть на модель ISO/OSI, как вам уже указали ранее. Как справедливо замечено, вы увидите, что в ваших требованиях смешаны части формата, отвечающие за различные уровни. После этого надо раскаяться и все-таки почитать про эту модель, она вам понадобится, если вы хотите реализовать хороший протокол.
Во-вторых, понять, что в первую очередь надо рассмотреть уровни модели от 8 и выше, которых в текущей редакции модели нет. Это требования к системе, в которой будет применяться протокол. Здесь поможет внимательное чтение ПМБука или даже ГОСТ на ТЗ для АСУ.
Вот, примерно накидал (здесь также смешаны уровни, но это и не статья):
Имеет смысл рассматривать сценарии использования на всех этапах жизненного цикла вашего оборудования. Например, может оказаться, что протокол предназначен для настройки системы обслуживающим персоналом, в этом случае часто удобно делать его текстовым. Для payload M2M протоколов часто используется JSON или XML, в том числе, со сжатием, в этом случае объем сравним с бинарным представлением. Библиотеки для работы с ними не очень сложные. Таким образом, п.1 можно вычеркнуть. Программисты серверной части скажут вам спасибо.
Можно проанализировать окружение: протокол нужен для связи между микроконтроллером и датчиком в пределах одной платы или для контроля транспортных средств в пределах региона? Система состоит из однородных или разнородных элементов? Протокол открытый или закрытый? Планируется ли расширение номенклатуры, совместимость с имеющимися устройствами или подключение устройств сторонних производителей? Например, если у вас внутренний протокол между электронными платами по шине SPI с сигналом #CS, то пп.2,3,4,5,6,8,12,15,16,17 можно вычеркнуть, если по шине I2C, то можно вычеркнуть пп.2,3,5,10,15.
Кроме того, стоит рассмотреть физические ограничения: вычислительная мощность узлов, энергопотребление, требуемая скорость обмена, задержки, надежность. Предполагаемая среда передачи данных и/или аппаратная реализация. Например, если интерфейс CAN, то п.2,4,5,6,7,8,10,15,17 не имеют смысла. Если оптика, то п.14 не выглядит необходимым.
Таким образом, аргументированным выглядит только п.13.
Вооружившись средствами редактирования электронных таблиц и моделью ISO/OSI следует определить требования к уровням сверху вниз, возможно, не все уровни модели будут необходимы:
Имеет смысл прикинуть API, лучше для каждого уровня.
Будет полезно описать виды передаваемых данных и требования к ним.
Также не лишним будет подумать над структурой сети: точка-точка, ведущий-ведомый, мультимастер, одноранговая сеть, ретрансляция т.п.
После этого станут яснее требования к алгоритмам взаимодействия узлов: handshaking, PnP, подписки, каналы, разделяемая память, квитирование, таймауты, арбитраж, асинхронные сообщения и т.п.
пп.1-4 повторять до просветления.
После этого оценить затраты на реализацию. Не стоит забывать про альтернативные варианты. (Имеет смысл их все-таки изучить, потому что CAN и ModeBus это немного про разное).
По теории ограничений — у него на предприятии должно было существовать узкое место, которое лимитировало выход, и в конечном счете — деньги.
С моей точки зрения, на тот момент узким местом были отделы продаж и развития.
И тогда окажется — что рынок взбаламутили, порцию недовольства от заказчиков получили, продажам заплатили — и в результате не заработали…
Надо сказать, что в целом собственник отличался здравомыслием - я участвовал в изменении процессов на предприятии. Описанная вами ситуация стала маловероятной - через фильтр конструкторов, снабженцев, производства, экономистов до реализации доходили далеко не все проекты.
Допустим, придет продажник и скажет, что за немало денег он может нам сделать x10 продаж. Дам я ему денег? Нет
Возможно, это плохой продажник...
А с точки зрения бизнеса как системы, и владельца — не был, не знаю, не уверен…
После вашего комментария не исключаю, что действительной, а не декларируемой целью было создание отдела управляемых менеджеров с прогнозируемым уровнем продаж на устоявшемся рынке. Возможно, он тоже был знаком с барабаном и веревкой.
Однажды вместе с продажниками участвовал в обсуждении с собственником процентов с продаж. Пытался объяснить, что выгодно установить прогрессивный процент (чем больше продал, тем выше процент премии). В ответ услышал такой же аргумент, в итоге собственник утвердил регрессивный процент. Результат: люди, которые могли развивать новые направления уволились, оставшиеся работают на оптимуме, выше которого напрягаться не имеет смысла.
Я довольно долго преподавал в одном из известных ВУЗов и имею сказать следующее:
на мой взгляд, дело в низкой стоимости труда специалистов с высшим образованием. Я считаю, что высшее образование на рынке труда РФ в большинстве случаев просто не окупается, хотя мне и неприятно это признавать, и имеет скорее статусное значение.
Фактически, рынок труда РФ существует в искусственно замкнутой среде и положение усугубляется. Поэтому для изменения ситуации в образовании нет предпосылок, какие бы прекрасные идеи здесь ни обсуждались.
Оплата труда в IT фактически конкурирует на открытом рынке. Как следствие, з/п существенно превышает среднюю. Собственно, поэтому автор и заметил несоответствие ожиданиям от образования с точки зрения работодателя.
Примерно 20 лет назад именно в таком форм-факторе (именно эта сборная подложка на DIN-рейку) был сделан блок телемеханики МТК-20. Реле, кстати, были съемные.
Идея хорошая, типа дешево и сердито, но не взлетело. А там где взлетело, упало. Сам лично заменял их в шкафах РЗА подстанций на следующее поколение, которое, кстати, до сих пор работает и выпускается.
Причина - выгорали дорожки на плате, также из-за длинных проводников сигналы ТС (дискретные) и ТИТ (аналоговые) из-за наводок при переключении реле давали ложные значения.
Я пытался учиться по отцовской книге "Радиоператор" 70-х годов, там насколько я помню, максимальная скорость достигалась тренировкой аккордов.
В итоге просто стер символы с клавиатуры, повесил над монитором рисунок расположения клавиш, и за пару недель научился. Проверил на вашем тренажере - 200 CPS. Что интересно - при наборе осмысленного текста скорость ощутимо выше. Возможно, стоит это учесть в вашей программе.
Кстати, какой протокол используете вы?
Вы правы, для таких применений Modbus не лучший выбор.
Однако, несмотря на древность, если необходимо обеспечить в оборудовании считывание данных и запись настроек на небольших скоростях, я бы рекомендовал использовать именно его.
Вообще-то, желание упорядочить требования к протоколу заслуживает одобрения, я считаю.
Хотя классификации подобного рода встречались и ранее
животные делятся на:
а) принадлежащих Императору,
б) набальзамированных,
в) прирученных,
г) молочных поросят,
д) сирен,
е) сказочных,
ж) бродячих собак,
з) включённых в эту классификацию,
и) бегающих как сумасшедшие,
к) бесчисленных,
л) нарисованных тончайшей кистью из верблюжьей шерсти,
м) прочих,
н) разбивших цветочную вазу,
о) похожих издали на мух.
Видите ли, формат пакета - технический компромисс, получающийся в результате анализа требований к протоколу, как части системы, обеспечивающей решение какой-то задачи. Поэтому начинать надо с другого.
Во-первых, посмотреть на модель ISO/OSI, как вам уже указали ранее. Как справедливо замечено, вы увидите, что в ваших требованиях смешаны части формата, отвечающие за различные уровни. После этого надо раскаяться и все-таки почитать про эту модель, она вам понадобится, если вы хотите реализовать хороший протокол.
Во-вторых, понять, что в первую очередь надо рассмотреть уровни модели от 8 и выше, которых в текущей редакции модели нет. Это требования к системе, в которой будет применяться протокол. Здесь поможет внимательное чтение ПМБука или даже ГОСТ на ТЗ для АСУ.
Вот, примерно накидал (здесь также смешаны уровни, но это и не статья):
Имеет смысл рассматривать сценарии использования на всех этапах жизненного цикла вашего оборудования. Например, может оказаться, что протокол предназначен для настройки системы обслуживающим персоналом, в этом случае часто удобно делать его текстовым. Для payload M2M протоколов часто используется JSON или XML, в том числе, со сжатием, в этом случае объем сравним с бинарным представлением. Библиотеки для работы с ними не очень сложные. Таким образом, п.1 можно вычеркнуть. Программисты серверной части скажут вам спасибо.
Можно проанализировать окружение: протокол нужен для связи между микроконтроллером и датчиком в пределах одной платы или для контроля транспортных средств в пределах региона? Система состоит из однородных или разнородных элементов? Протокол открытый или закрытый? Планируется ли расширение номенклатуры, совместимость с имеющимися устройствами или подключение устройств сторонних производителей? Например, если у вас внутренний протокол между электронными платами по шине SPI с сигналом #CS, то пп.2,3,4,5,6,8,12,15,16,17 можно вычеркнуть, если по шине I2C, то можно вычеркнуть пп.2,3,5,10,15.
Кроме того, стоит рассмотреть физические ограничения: вычислительная мощность узлов, энергопотребление, требуемая скорость обмена, задержки, надежность. Предполагаемая среда передачи данных и/или аппаратная реализация. Например, если интерфейс CAN, то п.2,4,5,6,7,8,10,15,17 не имеют смысла. Если оптика, то п.14 не выглядит необходимым.
Таким образом, аргументированным выглядит только п.13.
Вооружившись средствами редактирования электронных таблиц и моделью ISO/OSI следует определить требования к уровням сверху вниз, возможно, не все уровни модели будут необходимы:
Имеет смысл прикинуть API, лучше для каждого уровня.
Будет полезно описать виды передаваемых данных и требования к ним.
Также не лишним будет подумать над структурой сети: точка-точка, ведущий-ведомый, мультимастер, одноранговая сеть, ретрансляция т.п.
После этого станут яснее требования к алгоритмам взаимодействия узлов: handshaking, PnP, подписки, каналы, разделяемая память, квитирование, таймауты, арбитраж, асинхронные сообщения и т.п.
пп.1-4 повторять до просветления.
После этого оценить затраты на реализацию. Не стоит забывать про альтернативные варианты. (Имеет смысл их все-таки изучить, потому что CAN и ModeBus это немного про разное).
Описать форматы пакетов.
В упустили главное правило: "не начинайте колхозить протокол с формата пакетов"
С моей точки зрения, на тот момент узким местом были отделы продаж и развития.
Надо сказать, что в целом собственник отличался здравомыслием - я участвовал в изменении процессов на предприятии. Описанная вами ситуация стала маловероятной - через фильтр конструкторов, снабженцев, производства, экономистов до реализации доходили далеко не все проекты.
Возможно, это плохой продажник...
После вашего комментария не исключаю, что действительной, а не декларируемой целью было создание отдела управляемых менеджеров с прогнозируемым уровнем продаж на устоявшемся рынке. Возможно, он тоже был знаком с барабаном и веревкой.
Согласен с вашим замечанием - мой комментарий не понятен без предыстории.
Собственно, дебаты начались с того, что отменили линейную зависимость. По очевидной (для собственника) причине.
Рынок (производство оборудования) достаточно узкий, поэтому увеличение объема продаж требует сверхусилий.
Время от продажи до поставки от полугода до 2-х лет, поэтому равномерность не была проблемой.
Можно, например, сравнить затраты бюджета на образование СССР/РФ https://news.rambler.ru/education/39751029-traty-na-sotsialku-sssr-vs-rf/
Или рейтинги университетов.
Или з/п профессорско-преподавательского состава.
На мой взгляд, они согласуются с утверждением, что качество образования не стало выше.
Однажды вместе с продажниками участвовал в обсуждении с собственником процентов с продаж.
Пытался объяснить, что выгодно установить прогрессивный процент (чем больше продал, тем выше процент премии). В ответ услышал такой же аргумент, в итоге собственник утвердил регрессивный процент.
Результат: люди, которые могли развивать новые направления уволились, оставшиеся работают на оптимуме, выше которого напрягаться не имеет смысла.
расчет 43% по вашей ссылке относится к виртуальной сумме, которую на руки не получают. На руки получают 87% от этой суммы.
то есть, если рассматривать соотношение "деньги в казну / деньги на руки" выходит 43,2/87 = 49,7%. Это к вопросу о низких налогах в РФ.
Я довольно долго преподавал в одном из известных ВУЗов и имею сказать следующее:
на мой взгляд, дело в низкой стоимости труда специалистов с высшим образованием. Я считаю, что высшее образование на рынке труда РФ в большинстве случаев просто не окупается, хотя мне и неприятно это признавать, и имеет скорее статусное значение.
Фактически, рынок труда РФ существует в искусственно замкнутой среде и положение усугубляется. Поэтому для изменения ситуации в образовании нет предпосылок, какие бы прекрасные идеи здесь ни обсуждались.
Оплата труда в IT фактически конкурирует на открытом рынке. Как следствие, з/п существенно превышает среднюю. Собственно, поэтому автор и заметил несоответствие ожиданиям от образования с точки зрения работодателя.
Сейчас, например, кроме телевизора, много альтернативных каналов информации.
Тем не менее...
Примерно 20 лет назад именно в таком форм-факторе (именно эта сборная подложка на DIN-рейку) был сделан блок телемеханики МТК-20. Реле, кстати, были съемные.
Идея хорошая, типа дешево и сердито, но не взлетело. А там где взлетело, упало. Сам лично заменял их в шкафах РЗА подстанций на следующее поколение, которое, кстати, до сих пор работает и выпускается.
Причина - выгорали дорожки на плате, также из-за длинных проводников сигналы ТС (дискретные) и ТИТ (аналоговые) из-за наводок при переключении реле давали ложные значения.
Я пытался учиться по отцовской книге "Радиоператор" 70-х годов, там насколько я помню, максимальная скорость достигалась тренировкой аккордов.
В итоге просто стер символы с клавиатуры, повесил над монитором рисунок расположения клавиш, и за пару недель научился. Проверил на вашем тренажере - 200 CPS. Что интересно - при наборе осмысленного текста скорость ощутимо выше. Возможно, стоит это учесть в вашей программе.