Вывод: за потраченные средства, GM могла просто купить Toyota и Nissan:
Since 1980 GM has spent $45 billion on the automotive business. Capital spending appears to be almost inversely related to our levels of operating profit. And GM's forward capital spending plans are projected to be $34.7 billion over the period from 1986 through 1989. For $34.7 billion, given recent market valuations, GM could have purchased Toyota and Nissan.
Я, например, использую BPMN для описания общих бизнес-процесса и ДРАКОН для конкретных сценариев, пробовал таблицы параметров - гораздо сложнее воспринимается.
Действительно, для BPMN есть рисовалки, верификаторы и автоматизация, но особенности реализации в нем гораздо менее наглядны.
из моего опыта программирования интерфейсов пользователей оборудования (из этого можно сделать тот еще квест):
Взаимодействуя с системой пользователь создает в своем мозге ее модель.
Если поведение системы не соответствует модели, пользователь испытывает боль и негодование.
Задача программиста - при проектировании системы постараться, чтобы взаимодействие с системой как можно быстрее приводило к формированию в мозге пользователя той модели, которая запрограммирована.
мои наблюдения показывают, что модели на базе конечных автоматов (в т.ч. иерархических) гораздо понятнее (быстрее усваиваются), чем на базе цепочек действий, флагов, таблиц, наборов правил и т.п.
Мне довелось плотно работать в сфере госзакупок со стороны заказчика еще со времени появления 94-ФЗ и изменения законодательства для предотвращения разных схем я наблюдал в режиме реального времени. В итоге получился 44-ФЗ.
На мой взгляд, закон работает хорошо. Я могу ошибаться в деталях, но примерно так:
Для обеспечения участия всем участникам надо предоставить банковскую гарантию - что-то вроде кредитов в банке в объеме 5-10% от суммы конкурса на время проведения.
Для обеспечения контракта победителю надо предоставить банковскую гарантию на всю сумму контракта на время исполнения.
Для выполнения контракта победителю надо взять кредит в банке на закупку.
Все это время деньги покупателя лежат в банке, потому что конкурс нельзя объявлять до поступления средств на счет.
В итоге все спорят насчет конкурсных процедур, ФАС, ТЗ, а банки просто имеют 10-20% с каждой закупки.
Чтобы исполнители не отвлекались, деньги поступают осенью.
Ну, пример для обновления прошивки PIC привели выше (20 лет). Сейчас ресурсов обычно достаточно, поэтому не часто встречается. Но бит или байт стаффинг аппаратно реализуется во многих шинах.
Байт-стаффинг очень универсален -- подходит под любые скорости и устройства, не чувствителен к буферизации в устройствах ввода, его можно реализовать и отладить отдельно от верхних уровней протокола.
Реализовать и отладить выборку фреймов можно, но все равно придется обрабатывать ошибки - здесь все преимущества потеряются. Оправдано, на линии точка-точка с малыми потерями если скорость определяется ресурсами микроконтроллера
Неочевидные преимущества для программной реализации. С какими альтернативами контроля границ пакета вы сравниваете?
Насчет контролируемой избыточности: тоже сомнительный аргумент, это понадобится разве что на грани пропускной способности линии. Но в этом случае, скорее BER будет расти так, что все преимущества будут нивелированы.
При этом, байт-стаффинг вообще прост для аппаратной реализации, потому что не требует больших ресурсов - можно сразу пакеты в память начинать выдавать, например Я однажды использовал для синхронизации устройств по UART, сейчас не уверен, что поступил бы также.
Спасибо. Типичный протокол для своей области применения. Запомню, возможно, пригодится.
Модель представления устройств примерно как у Modbus, только адресация 3 байта.
Байт-стаффинг обычно применяется, если необходимо выделять пакеты в потоке байтов на шине при спорадическом подключении. Или при недостатке ресурсов. Судя по всему, памяти было впритык.
В целом, я обычно как раз Modbus применяю в таких случаях - области памяти можно страницами переключать. Не оптимально, зато стандартно - тестирование и документирование проще.
Прошу прощения, поясню, я думаю, эту историю должны держать в уме все, кто занимается робототехникой:
40 лет назад для борьбы с наступлением японских производителей GM открыла полностью роботизированную "Factory of Future": https://www.nytimes.com/1984/10/20/business/gm-factory-of-future-will-run-with-robots.html
через 10 лет закрыла: https://apnews.com/article/3e78974c3c94990405ce607326d29223
Вывод: за потраченные средства, GM могла просто купить Toyota и Nissan:
здесь можно почитать: Case Study: GM and the Great Automation Solution https://mba.tuck.dartmouth.edu/pages/faculty/syd.finkelstein/case_studies/01.html
Спасибо за познавательную статью, подход выглядит перспективно, практически "Factory Of Future"...
Стек выбранных технологий тоже произвел впечатление
переносимый язык позволяет кроссплатформенную отладку
я не фанат Форта, просто ваши комментарии противоречат целям заявленным в статье
Вы абсолютно правы.
Продолжу: в статье предложено свести оптимизированные к архитектуре синтаксисы ассемблеров к некоему обобщенному.
Как вы считаете, этот подход позволит использовать "преимущества современных процессоров с кучей регистров"?
...потом появится желание обеспечить повторное использование программ для различных ядер, чтобы по два раза не переписывать
...для этого понадобится привести архитектуры к одному общему виду
...называется это Форт
это распространенная ошибка, на самом деле:
сначала платится налог ~30% и 100% перечисляется на з/п
затем с этих 100% платится 13% НДФЛ, 87% - деньги на руки
т.е. на руки получается 87 из 130. Т.е. налоги 43. Это примерно 50% от наличных денег на руки
А теперь, ребята, посмотрите, какой у нас был реактор...
Это немного разные области.
Я, например, использую BPMN для описания общих бизнес-процесса и ДРАКОН для конкретных сценариев, пробовал таблицы параметров - гораздо сложнее воспринимается.
Действительно, для BPMN есть рисовалки, верификаторы и автоматизация, но особенности реализации в нем гораздо менее наглядны.
из моего опыта программирования интерфейсов пользователей оборудования (из этого можно сделать тот еще квест):
Взаимодействуя с системой пользователь создает в своем мозге ее модель.
Если поведение системы не соответствует модели, пользователь испытывает боль и негодование.
Задача программиста - при проектировании системы постараться, чтобы взаимодействие с системой как можно быстрее приводило к формированию в мозге пользователя той модели, которая запрограммирована.
мои наблюдения показывают, что модели на базе конечных автоматов (в т.ч. иерархических) гораздо понятнее (быстрее усваиваются), чем на базе цепочек действий, флагов, таблиц, наборов правил и т.п.
я бы сказал: лишь бы его потом не переписывать
особенно Модильяни
Спасибо за разъяснение текущего положения дел, давно отошел от этого.
Если не затруднит, по пунктам 3 и 4 как сегодня обстоят дела? Я имею ввиду авансирование.
Мне довелось плотно работать в сфере госзакупок со стороны заказчика еще со времени появления 94-ФЗ и изменения законодательства для предотвращения разных схем я наблюдал в режиме реального времени. В итоге получился 44-ФЗ.
На мой взгляд, закон работает хорошо. Я могу ошибаться в деталях, но примерно так:
Для обеспечения участия всем участникам надо предоставить банковскую гарантию - что-то вроде кредитов в банке в объеме 5-10% от суммы конкурса на время проведения.
Для обеспечения контракта победителю надо предоставить банковскую гарантию на всю сумму контракта на время исполнения.
Для выполнения контракта победителю надо взять кредит в банке на закупку.
Все это время деньги покупателя лежат в банке, потому что конкурс нельзя объявлять до поступления средств на счет.
В итоге все спорят насчет конкурсных процедур, ФАС, ТЗ, а банки просто имеют 10-20% с каждой закупки.
Чтобы исполнители не отвлекались, деньги поступают осенью.
Ну, например, грузовик или автобус обдал грязью ветровое стекло. Автомат может не среагировать. Вряд ли получиться ждать до светофора.
и часто возникает необходимость по полной утилизации линии?
Ну, пример для обновления прошивки PIC привели выше (20 лет). Сейчас ресурсов обычно достаточно, поэтому не часто встречается. Но бит или байт стаффинг аппаратно реализуется во многих шинах.
Реализовать и отладить выборку фреймов можно, но все равно придется обрабатывать ошибки - здесь все преимущества потеряются. Оправдано, на линии точка-точка с малыми потерями если скорость определяется ресурсами микроконтроллера
Неочевидные преимущества для программной реализации. С какими альтернативами контроля границ пакета вы сравниваете?
Насчет контролируемой избыточности: тоже сомнительный аргумент, это понадобится разве что на грани пропускной способности линии. Но в этом случае, скорее BER будет расти так, что все преимущества будут нивелированы.
При этом, байт-стаффинг вообще прост для аппаратной реализации, потому что не требует больших ресурсов - можно сразу пакеты в память начинать выдавать, например Я однажды использовал для синхронизации устройств по UART, сейчас не уверен, что поступил бы также.
Спасибо. Типичный протокол для своей области применения. Запомню, возможно, пригодится.
Модель представления устройств примерно как у Modbus, только адресация 3 байта.
Байт-стаффинг обычно применяется, если необходимо выделять пакеты в потоке байтов на шине при спорадическом подключении. Или при недостатке ресурсов. Судя по всему, памяти было впритык.
В целом, я обычно как раз Modbus применяю в таких случаях - области памяти можно страницами переключать. Не оптимально, зато стандартно - тестирование и документирование проще.