Мне довелось плотно работать в сфере госзакупок со стороны заказчика еще со времени появления 94-ФЗ и изменения законодательства для предотвращения разных схем я наблюдал в режиме реального времени. В итоге получился 44-ФЗ.
На мой взгляд, закон работает хорошо. Я могу ошибаться в деталях, но примерно так:
Для обеспечения участия всем участникам надо предоставить банковскую гарантию - что-то вроде кредитов в банке в объеме 5-10% от суммы конкурса на время проведения.
Для обеспечения контракта победителю надо предоставить банковскую гарантию на всю сумму контракта на время исполнения.
Для выполнения контракта победителю надо взять кредит в банке на закупку.
Все это время деньги покупателя лежат в банке, потому что конкурс нельзя объявлять до поступления средств на счет.
В итоге все спорят насчет конкурсных процедур, ФАС, ТЗ, а банки просто имеют 10-20% с каждой закупки.
Чтобы исполнители не отвлекались, деньги поступают осенью.
Ну, пример для обновления прошивки PIC привели выше (20 лет). Сейчас ресурсов обычно достаточно, поэтому не часто встречается. Но бит или байт стаффинг аппаратно реализуется во многих шинах.
Байт-стаффинг очень универсален -- подходит под любые скорости и устройства, не чувствителен к буферизации в устройствах ввода, его можно реализовать и отладить отдельно от верхних уровней протокола.
Реализовать и отладить выборку фреймов можно, но все равно придется обрабатывать ошибки - здесь все преимущества потеряются. Оправдано, на линии точка-точка с малыми потерями если скорость определяется ресурсами микроконтроллера
Неочевидные преимущества для программной реализации. С какими альтернативами контроля границ пакета вы сравниваете?
Насчет контролируемой избыточности: тоже сомнительный аргумент, это понадобится разве что на грани пропускной способности линии. Но в этом случае, скорее BER будет расти так, что все преимущества будут нивелированы.
При этом, байт-стаффинг вообще прост для аппаратной реализации, потому что не требует больших ресурсов - можно сразу пакеты в память начинать выдавать, например Я однажды использовал для синхронизации устройств по UART, сейчас не уверен, что поступил бы также.
Спасибо. Типичный протокол для своей области применения. Запомню, возможно, пригодится.
Модель представления устройств примерно как у Modbus, только адресация 3 байта.
Байт-стаффинг обычно применяется, если необходимо выделять пакеты в потоке байтов на шине при спорадическом подключении. Или при недостатке ресурсов. Судя по всему, памяти было впритык.
В целом, я обычно как раз Modbus применяю в таких случаях - области памяти можно страницами переключать. Не оптимально, зато стандартно - тестирование и документирование проще.
Вы правы, для таких применений 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. Реле, кстати, были съемные.
Идея хорошая, типа дешево и сердито, но не взлетело. А там где взлетело, упало. Сам лично заменял их в шкафах РЗА подстанций на следующее поколение, которое, кстати, до сих пор работает и выпускается.
Причина - выгорали дорожки на плате, также из-за длинных проводников сигналы ТС (дискретные) и ТИТ (аналоговые) из-за наводок при переключении реле давали ложные значения.
Спасибо за разъяснение текущего положения дел, давно отошел от этого.
Если не затруднит, по пунктам 3 и 4 как сегодня обстоят дела? Я имею ввиду авансирование.
Мне довелось плотно работать в сфере госзакупок со стороны заказчика еще со времени появления 94-ФЗ и изменения законодательства для предотвращения разных схем я наблюдал в режиме реального времени. В итоге получился 44-ФЗ.
На мой взгляд, закон работает хорошо. Я могу ошибаться в деталях, но примерно так:
Для обеспечения участия всем участникам надо предоставить банковскую гарантию - что-то вроде кредитов в банке в объеме 5-10% от суммы конкурса на время проведения.
Для обеспечения контракта победителю надо предоставить банковскую гарантию на всю сумму контракта на время исполнения.
Для выполнения контракта победителю надо взять кредит в банке на закупку.
Все это время деньги покупателя лежат в банке, потому что конкурс нельзя объявлять до поступления средств на счет.
В итоге все спорят насчет конкурсных процедур, ФАС, ТЗ, а банки просто имеют 10-20% с каждой закупки.
Чтобы исполнители не отвлекались, деньги поступают осенью.
Ну, например, грузовик или автобус обдал грязью ветровое стекло. Автомат может не среагировать. Вряд ли получиться ждать до светофора.
и часто возникает необходимость по полной утилизации линии?
Ну, пример для обновления прошивки PIC привели выше (20 лет). Сейчас ресурсов обычно достаточно, поэтому не часто встречается. Но бит или байт стаффинг аппаратно реализуется во многих шинах.
Реализовать и отладить выборку фреймов можно, но все равно придется обрабатывать ошибки - здесь все преимущества потеряются. Оправдано, на линии точка-точка с малыми потерями если скорость определяется ресурсами микроконтроллера
Неочевидные преимущества для программной реализации. С какими альтернативами контроля границ пакета вы сравниваете?
Насчет контролируемой избыточности: тоже сомнительный аргумент, это понадобится разве что на грани пропускной способности линии. Но в этом случае, скорее BER будет расти так, что все преимущества будут нивелированы.
При этом, байт-стаффинг вообще прост для аппаратной реализации, потому что не требует больших ресурсов - можно сразу пакеты в память начинать выдавать, например Я однажды использовал для синхронизации устройств по UART, сейчас не уверен, что поступил бы также.
Спасибо. Типичный протокол для своей области применения. Запомню, возможно, пригодится.
Модель представления устройств примерно как у Modbus, только адресация 3 байта.
Байт-стаффинг обычно применяется, если необходимо выделять пакеты в потоке байтов на шине при спорадическом подключении. Или при недостатке ресурсов. Судя по всему, памяти было впритык.
В целом, я обычно как раз Modbus применяю в таких случаях - области памяти можно страницами переключать. Не оптимально, зато стандартно - тестирование и документирование проще.
Кстати, какой протокол используете вы?
Вы правы, для таких применений 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. Реле, кстати, были съемные.
Идея хорошая, типа дешево и сердито, но не взлетело. А там где взлетело, упало. Сам лично заменял их в шкафах РЗА подстанций на следующее поколение, которое, кстати, до сих пор работает и выпускается.
Причина - выгорали дорожки на плате, также из-за длинных проводников сигналы ТС (дискретные) и ТИТ (аналоговые) из-за наводок при переключении реле давали ложные значения.