Настройка которой не бывает – часть 4. Мониторинг EGAS.

Предыдущая часть

Сегодня мы поговорим об очень важной теме — мониторинге положения электронной дроссельной заслонки.

Технология Drive by Wire (управление по проводам) является ведущей концепцией при проектировании систем управления транспортных средств вот уже более 20 лет. Практика реализации этой концепции для легковых авто приводит нас к использованию для управления ДВС электронной педали и электронной дроссельной заслонки (Egas). В этом году в мире было продано 77 миллионов легковых автомобилей — так или иначе абсолютное большинство из них имеет на борту Egas. А в целом в эксплуатации, находится более миллиарда единиц таких авто. Сегодня я расскажу вам, на чем основана безопасность этой системы, и почему мы каждый день доверяем свою жизнь системе, которая не доверяет ничему — даже самой себе. И почему на самом деле "тойота не убивает нас". Эта статья будет наиболее полезна инженерам по проектированию систем безопасности и прочим юным ардуинщикам.

Для примера я возьму систему Bosch ME7.5 образца 1998 года, систему 20-ти летней давности, но в таких вещах как концепция безопасности ее возраст со временем лишь только делает ее лучше, ведь с каждым годом, ее безопасное поведение только подтверждает верность заложенных в нее идей. Но перед этим будет небольшое лирическое отступление.

Большую помощь нам оказали специалисты Porsche в выборе конструкции замка боковой двери. Они похвалили замок, разработанный нашим конструктором В. Епишиным, отметив его простоту и компактность, но посоветовали всё же принять замок фирмы Bomoro. Особо отметив при этом, что в нём запирающий элемент удерживается вторым подвижным элементом наподобие борцовского приёма «захват».

Разговор простым не получился. Я возразил, что в нашем замке запирающий элемент подпружинен, поэтому он никогда не отойдёт от запираемого элемента.

Тогда начальник КБ механизмов г-н Колель положил пальцы на край стола и сказал: «Представьте себе, что пальцы – запирающий элемент, а стол – запираемый. Ведь при движении автомобиля происходит вибрация (он поёрзал пальцами), и ваш запирающий элемент может от края стола отойти».

Я повторил, что запирающий элемент нагружен пружиной и поэтому он не сдвинется. Г-н Колель28 сказал: «А вибрация?». И вновь поёрзал пальцами.

Я опять не согласился.

Тогда он и задал вопрос:

– Вы гарантируете, что Ваш замок не откроется, скажем, один из тысячи?

– Да.

– А один из 10 тысяч?

– Да.

– А один из 100 тысяч?

Я подумал: «В год будем выпускать 220 тысяч автомобилей 2108. И надо быть твёрдо уверенным, что даже на одном-единственном из этих автомобилей замок не откроется самопроизвольно».

А мой оппонент не торопит и добавляет:

– Учтите, что в Америке вы тоже собираетесь продавать свои автомобили, а там судебный процесс стоит очень и очень дорого. Был такой случай, когда у владельца автомобиля Porsche-911 пассажир на повороте выпал из автомобиля и погиб. В конце концов нам удалось всё же доказать, что замок двери не мог открыться самопроизвольно. Фирма Porsche этот процесс выиграла, но каких трудов это стоило! (том 2й "Выской мысли пламень" из истории разработки восьмерки)

Концепция безопасности EGAS- свод правил и алгоритмов обеспечивающих такое поведение системы, которое в случае нештатной или нечеткой ситуации позволяет минимизировать или вообще исключить человеческие жертвы и повреждения. Практически все серьезные техногенные катастрофы современности (будь то "Чернобыль", или "Cаяно-Шушенская ГЭС") в своей первопричине имеют либо нарушение концепции безопасности, либо плохую концепцию безопасности by design, либо совокупность обоих этих сущностей. Применительно к нашему случаю концепцией безопасности мы будем считать некий набор правил, реализованный посредством программно аппаратных средств системы управления двигателем, позволяющих избегать неконтролируемого открытия электронной дроссельной заслонки а следовательно — неконтролируемого увеличения скорости автомобиля, и таким образом травмирования или гибели участников движения, либо повреждения как самого автомобиля так и других транспортных средств на дороге.

С точки зрения концепции безопасности EGAS наша система управления может находиться в 3-х состояниях:

1) Рабочем (или аварийном по некритичным датчикам) — в котором абсолютно корректно производится управление электронной заслонкой с формальным доказательством этой корректности. Электронная заслонка принимает нужные положения в зависимости от желаемого момента двигателя и происходит постоянный непрерывный мониторинг исправности всех компонентов и корректности реализации законов ее управления .

2) Аварийном по Egas — с наличием критической ошибки в датчиках исполнительных механизмах или алгоритмах системы Egas. Когда у системы по тем или иным причинам недостаточно информации для корректного управления электронной дроссельной заслонкой. В этом режиме напряжение с электродвигателя заслонки снято. Пружиной механически заслонка приводится в home position — обороты двигателя 3000-4000 и можно очень медленно ехать с небольшой нагрузкой. такой режим называется LIMP HOME.

3) Режим циклического сброса ЭБУ — произошел очень серьезный отказ в железе или ПО ЭБУ. Двигатель запустить не возможно в принципе. Автомобиль может ехать по дороге разве что только на стартере или веревке.

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

Надеюсь вы уже знаете (было в предыдущих частях), что данная система управления построена на базе так называемых "моментных моделей двигателя" — это класс систем в которых центральным управляемым параметром является момент двигателя и так или иначе, все управление, идет в терминах либо момента (численное значение на том или ином узле) либо эффективности (% от разницы моментов между узлами системы либо возможными ее состояниями). Да и вообще все управление двигателем у нас по сути сводиться к простой формуле — момент либо растет, либо падает, либо остается неизменным.

Теперь к делу. Для начала давайте посмотрим на нашу систему с точки зрения источников запросов на увеличение или уменьшение момента извне.

Выше вы видите примитивную блок схему основных компонентов ЭСУД c EGAS. Сразу можно отметить, что все датчики участвующие алгоритме исходя из нашей стратегии безопасности специально сделаны избыточными, это сделано исключительно для надежного обнаружения отказов, а вовсе не для их парирования. Кроме того, датчики сделаны таким образом, чтоб могли быть обнаружены абсолютно любые типы отказов. Например: на дорожке 1 положения педали, сигнал растет от 0.5в до 4.5в при нажатии на педаль, сигнал же на 2й дорожке при этом падает от 4.5в до 0.5в. Состояние педали тормоза вообще передается 2-ми сигналами разной полярности и 3-м сигналом в виде сообщения по шине CAN от блока ABS. Таким образом мы можем обнаруживать отказы типа обрывов или коротких замыканий сигналов на другие сигналы, или искажений показаний в результате износа дорожек. Железно тоже все надежно — контакты в разъемах цепей этих датчиков выполнены исключительно с покрытием клемм золотом, а все провода не имеют соединений и подключены точка-точка… Так же имея два сигнала с разными показаниями, мы можем выбрать то значение положения которое для данного компонента будет наиболее безопасным по цепи запроса (меньшее для педали) или наоборот наиболее опасным по цепи реализации (большее для дросселя). Т.е. предполагать самый худший случай развития событий аварии системы.

И так у нас есть несколько источников запроса момента. — Запрос драйвера на увеличение момента — выполненный в виде электронной педали акселератора. Запрос драйвера на торможение (уменьшение момента) — в виде сигнала педали тормоза и этот сигнал имеет более высокий приоритет в цепи запросов момента — если будут нажаты обе педали — такое состояние называется brake override и машина будет тормозить. Запрос от системы круиз контроля и запрос от других источников (например система MSR или ЭБУ АКПП)…

Впрочем, про то как Egas у нас устроен "снаружи" давно есть 100500 статей — давайте лучше смотреть, как он устроен внутри, этого то вам мало кто расскажет.

И так как видите — микроконтроллеров в этой системе ДВА. Основной в котором работает все ПО ЭБУ — в качестве него у нас Сименс 80с167. И вспомогательный так называемый микроконтроллер монитора, в качестве которого используется моторола 68HC05. Микроконтроллеры находятся в постоянном взаимодействии друг с другом, в постоянном круговороте байт, использующихся для проверок друг друга и самопроверок. В основе этих проверок лежат т.н. цепи Маркова.

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

Сам драйвер (мост из 4-х полевых транзисторов для управления DC мотором) тоже не совсем простой — на его борту имеется схема контроля истинности, это логическая матрица на которую заводятся все входы и выходы драйвера, для одной лишь единственной цели — сформировать сигнал ошибки. Сигнал ошибки формируется при любой проблеме истинности (несоответствии фактических напряжений на выходе драйвера логике сигналов на его входе). Он может определять пробой своих транзисторов или силовое замыкание проводов выходов на двигатель привода заслонки на +12 или землю. Этот сигнал ошибки немедленно сбрасывает ЭБУ т.к. это очень серьезная неисправность которую нельзя парировать ничем.

Раз уж мы заговорили о сбросе — давайте посмотрим как ASIC CC650 формирует сигналы сброса микроконтроллеров в различных ситуациях (вообще он много чего еще делает но сейчас нас интересует лишь эта его функция).

Тут можно видеть, что любой сброс, будь то программный или аппаратный инициированный любым источником, так или иначе распространиться на все микроконтроллеры и исполнительные устройства в ЭБУ. При этом все они обязаны перейти в неактивные состояния. Так же видно, что сбросить систему может или чип питания (при аварии питания) или любой из микроконтроллеров.

И так с сбросами все понятно. Программы в контроллерах стартовали — и мы начнем с самых простых вещей. Должны пройти тесты ОЗУ-ПЗУ… В ПЗУ должно находиться то, что мы туда положили. А ОЗУ должно быть исправно — поэтому при каждом включении питания и первом запуске ЭБУ обязательно производится тесты всех областей ОЗУ и ПЗУ в обоих микроконтроллерах, для ПЗУ cчитается CRC32 а ОЗУ заполняется набором данных в виде собственных адресов в прямом и инверсном виде. Любая неисправность на этом этапе проверки в любом из микроконтроллеров снова ведет за собой программный сброс! Если эта неисправность не может быть устранена после сброса — ЭБУ не запустится, поскольку будет находиться в постоянном циклическом сбросе. Таким образом сразу исключаются варианты запуска программы при серьезном аппаратном дефекте памяти. Вещи казалось бы очень простые — но они позволяют сразу избежать огромное количество проблем. Один дефектный байт в памяти и поведение программы может стать абсолютно непредсказуемым. Поэтому этот вариант надо сразу исключить еще на этапе запуска программы. Мы ведь не доверяем нашей памяти…

Проверки выполнены, память вроде в норме — стартовало наше ПО на уровне 1, собственно операционная система реального времени ERCOS, сам алгоритм управления двигателем включая алгоритмы контроля положения заслонки и вся диагностика датчиков и исполнительных механизмов, логика обхода отказов, обмены по CAN шине — в общем все, что нужно, чтоб двигатель работал. Можем ли мы доверять этому ПО?! Конечно нет! Дело в том, что это реально непознаваемая уйма говнокода — там реально есть функции в 20 экранов с 10-ками тысяч глобальных переменных, и 10-ками тысяч таблиц калибровочных данных, списки задач в растрах ОС не влезают в несколько экранов текста. Мы не доверяем этому коду! Мы не доверяем программистам которые его пишут. И компилятору которым его собрали — мы тоже не доверяем! Поскольку корректность работы всего этого кода не возможно обеспечить никакими методами в принципе — да это собственно и не нужно. Нужно, чтоб дроссель не открывался если не нажали на педаль! Поэтому в ПО ЭБУ введена небольшая полностью инкапсулированная область памяти, где располагается специальная программа — монитор. Это программа, которая на нашей картинке обозначена как "программа мониторинга на уровне 2". Цель этой программы — контроль запрашиваемого извне и фактического моментов двигателя (как и все ПО в ЭБУ программа монитора так же реализована в терминах "момента") и реакция если фактический момент больше допустимого с учетом некоего заданного порога в точности и времени.

Программа выполняется в 10мс растре ОС однако все ее функции распределены по 4-м последовательным растрам, для полного выполнения всех задач программы мониторинга микроконтроллеру требуется 40мс. Проектное время реакции в худших условиях — 400мс. Т.е. всего лишь 0.4 секунды есть у системы на то, чтоб сойти с ума разогнать вас до опасной скорости и ударить об столб. (боюсь например в современной вялой егазной калине за 0.4 секунды не получится даже понять, что что-то вообще попыталось куда-то там ускорится, да и 1.8 турбо — хоть и по резвее, но особо даже не раздуется на своей ТД03)… Программа мониторинга написана таким образом, что не использует абсолютно никаких библиотек основного ПО — мы им не доверяем. Она имеет все строго лишь необходимые ей копии библиотечных функций в своем собственном участке памяти. Программа использует укороченные изолированные калибровки системы, строго для своего функционирования, в 8-ми битном представлении, и в масштабе 3D таблиц 8x8, c интерполяцией. Большинство расчетов так же идет в размерности 8 бит. Причина проста — программе не нужен точный ответ на ее вопросы. Ей нужно быстрый! Ведь если у вас допустимый момент 90% а фактический момент 100% — то вообще ничего страшного не происходит. Другое дело если запрос момента 10% а фактический момент 90% — это уже беда, и на это надо реагировать, а чтоб это понять и реагировать, достаточно и копий калибровок в усеченном виде и расчетов в 8-ми битных пространствах значений.

Из блок схемы назначение каждого модуля должно быть понятно. Наверно стоит объяснить, что такое "мониторинг реакции на ошибки"… Дело в том, что у нас на этом уровне вообще любая реакция на ошибку — заставить систему отключить силовые каскады драйвера электронного дросселя, но сами на этом уровне, мы отключить их не можем — поскольку управление этим портом находится на уровне 1 в основной программе, она кстати тоже может отключить дроссель, если ей, что то не нравится, и у нее более развитая и полная система диагностики. Но есть одна проблема — мы не можем ей доверять! И мы не доверяем! Активируя этот запрос, выставкой бита B_i_ska_um — в следующем цикле выполнения программы монитора, через 40мс, мы проверим непосредственным чтением из порта, что основная программа выполнила нашу вежливую и настойчивую просьбу и силовые каскады драйвера Egas действительно отключены — и если это вдруг не так, вся система будет мгновенно сброшена командой swrst, в результате чего, на аппаратном уровне прекратиться вообще какое либо управление. Это и будет нашей "реакцией на реакцию".

Теперь немного о том, чего нет на блок схеме — конечно при каждом старте запускается тест ОЗУ. Но даже если ОЗУ исправно — где гарантия. что мы в нашей программе прочитаем оттуда то, что сами туда положили? вдруг пока исполнялся говнокод 1-го уровня какая то зараза взяла и модифицировала нашу внутреннюю переменную из программы монитора, или тяжелая заряженная частица не вовремя пролетела через корпус нашего микроконтроллера. Для работы нам надо создать цепь доверия нашим переменным… Для этого все переменные программы мониторинга мы будем хранить в виде двух копий — прямой (суффикс _um в названии) и инверсной (суффикс _ur в названии) и по возможности по дальше друг от друга, при этом в любой момент когда нам надо получить значение переменной мы читаем сразу обе копии приводим инверсную к прямой через XOR и сравниваем их. В случае обнаружения любой разницы в них — силовые цепи Egas отключаются немедленно. Причем мы храним аж в 3-х местах признак того, что Egas должен быть отключен.

Далее опять тест ПЗУ! Да в самом начале при запуске мы уже тестировали и ОЗУ и ПЗУ — но это было давно и не правда и тому тесту мы не доверяем и поэтому при каждом старте монитора раз в 40мс ПЗУ тестируются заново — но только лишь очень небольшие области буквально в 3кб которые занимает сам монитор и его библиотеки и калибровки. Потому, что корректность работы монитора в отличие от основного ПО уровня 1 должна быть обеспеченна в каждом конкретном случае — а это значит мы должны проверять память связанную с кодом и данными на уровнях 2 и 3 непрерывно перед выполнением программ из нее.

Выполнение программ говорите? а оно есть — это выполнение?! Мы вообще доверяем операционной системе ERCOS? конечно нет! Тогда как мы поймем, что программы на нашем втором уровне — вообще выполняются?! Вдруг операционная система халявит и пропускает весь растр 10мс. А что если какая то атомарная функция из нашей программы мониторинга начала выполняться и вдруг по каким то причинам управление было прервано и она "сделала" лишь на половину то, что должна была сделать?! Что-же — самое время разобраться с этим вопросом. Но сначала давайте поймем, как идеи, предложенные гениальным математиком Марковым в конце 19-го века, были применены в ЭБУ в конце века 20-го и в конечном счете, как они не дают проклятой тойоте нас убивать в веке 21-м…

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

И так наши микроконтроллеры непрерывно общаются. Настало время понять — "о чем"… Собственно "ума" у 68HC05 не особо много — поэтому и "лексикон" у него бедноват. Маленькая старая и очень надежная 8-ми битка — маленькая масочная программа, написанная на ассемблере. Собственный кварцевый резонатор. Он может лишь послать нам некий "запрос", получить некий "ответ" и на основе этого ответа сделать далеко идущие выводы, в виде реакции на аж 2-х своих ногах выходах. Еще у него есть один вход который выбирает режим — нормальный или "flash programming mode" но об этом позже. Сначала разберемся, что же именно он шлет в основной MCU и что от него в итоге хочет получить.

А шлет он нам всего то 4-х битное число. Младший нибл 8-ми битного сдвигового регистра, используемого как генератор псевдослучайной последовательности по простому закону. На это число мы должны послать ему ответ… И ответ может быть верным или не верным. Таблица истинности у запросов и ответов определяющая верность тоже очень простая:

Что же будет если ответ верный — да в общем то ничего. Разве что внутренний счетчик ошибок уменьшится на единицу, пока не достигнет нуля.

А вот если ответ не верный или не получен по каким то причинам — счетчик ошибок увеличится сразу на три единицы. Дальше все зависит от содержимого счетчика. Значение >10 приводит к активному ESENSM(ESRST) и драйверы ЭБУ включая Egas будут отключены, значение >13 — сброс системы сигналом SWRST_SM. Собственно все…

Ну и раз уж начали, тут же опишем спец режим "Flash programming mode" — в него система переходит, когда обновляется микропрограмма основного контроллера. Делается это переводом порта P3.5 в состояние логической единицы. "Запросы" при этом не подаются и система не может быть сброшена MCU монитора — однако, чтоб не нарушать нашу концепцию безопасности в этом режиме сигнал ESENSM активен, и таким образом драйверы мотроника включая драйвер электронной дроссельной заслонки аппаратно отключены. Кроме того, если каким то образом обороты двигателя не = 0 — система принудительно покидает режим программирования flash, сбрасывая P3.5 и процесс отправки запросов и получения ответов как и собственно "мониторинг" возобновляется…

Давайте посмотрим как выглядит наша коммуникация 2-х микропроцессоров во времени в растре ОС 10мс.

Да а какой вопрос то мы решали? — ах да. Мы не доверяем ОС, и не понимаем выполняет ли она нашу программу мониторинга… Собственно весь геморой с обменом и 2м процессором для этого нам и нужен. Из полученного числа от генератора ПСП контроллера монитора мы сформируем цепь доверия!

И так наша первая Марковская цепь событий. У нас есть 28 атомарных функций мониторинга (n=28) в нашей программе мониторинга второго уровня и есть некое 16-битное значение в uma_res на выходе после 4-х последовательно выполненных 10мс растров. Так вот, в случае если все 28 функций были корректно начаты и корректно завершены (последовательность значения не имеет) — для каждого из 16 входных значений существует лишь одно выходное в пространстве 16-ти бит (одно из 65536) которое будет верным. Все остальные — ложны (что то не было выполнено, либо не было завершено)! "Декодер ответа" сопоставляет прямым сравнением 16 верных значений и выдает микропроцессору монитора ответ в соответствии с таблицей истинности запрос ответ (хотя сам ее не содержит).

А я говорил, что процессору мы тоже не доверяем?

Нет конечно на каком то уровне мы не можем не доверять процессору. Как процессор с мертвым ALU может нам CRC32 то корректно посчитать, он дальше теста ПЗУ не пойдет. но не все в процессоре так или иначе в ALU происходит. Умножение деление обычно в процессоре в виде отдельных модулей довольно автономных реализовано. Что если в нашей кремниевой технологии есть какой то дефект? что если этот дефект проявит себя через много много лет? Что если это случится в модуле умножителя? Можем ли мы доверять учебнику математики, где пишут что 2*2=4 — а то вдруг как приказом минобраза укажут, что 5 уже давно — эээ стопэ стопэ…

Именно поэтому в формирование части ответа введены умножение и деление на константы. По сути эти константы приводят к тому, что MEND_C=UFM_PTR*7 но если умножение и деление "сломались" — правильного ответа в цепи событий мы не получим. (и скажу вам по секрету — этот процессор на самом деле разрабатывали те, кто эту концепцию писал, и они знают что делают).

И так мы получили в процессор монитора верный ответ — теперь мы точно знаем, что наша программа монитора выполняется, что наш основной процессор как то там вроде бы работает. Мы точно знаем, что на 1-м уровне нас не просто слышат, но и слушаются. Но выполняется ли сам наш монитор правильно?! Можем ли мы сейчас доверять _сами себе_?! своей собственной, компактной, и понятной на все 100% программе?! ну короче — вы поняли ответ… Настало время нам надо создать цепь доверия своей программе. Как вообще программисты понимают, что своей программе можно доверять? Ну наверно они создают системы тестирования с некоторыми векторами ожидая на выходе получить какие то конкретные данные связанные с этими векторами, значит и мы сделаем то же самое.

Уровень 2' — в нем мы выполняем АБСОЛЮТНО ТОЧНУЮ КОПИЮ нашей программы монитора уровня 2, использующую те же самые калибровки, только вот на вход ее мы подаем не настоящие параметры для мониторинга, а специально подготовленные 16 наборов из тестовых данных (находятся в тех же калибровках по соседству), включающих абсолютно все "входы" в разных комбинациях, причем комбинациях, характерных как для "нормальной работы системы" так и для "сбоев" (копия в виде B_i_ska_uc=1 в этом случае должна отобразить реакцию на сбой). Все выходы мы просто суммируем и посылаем в тот же декодер ответа. Как и в случае проверки выполнения в пространстве из 65536 возможных вариантов у нас будет лишь 16 валидных для каждого из 16 возможных на входе, которые будут проверены в декодере ответа прямым сравнением. Верные ответы можно получить лишь в одном случае — если все функции монитора 2d-3d lookup, математика, интерполяции, значения калибровочных данных и тестовых векторов, реакции — работают корректно. Таким образом по сути ответ формируется из пространства возможных значений в 32 бита и только единственное значение будет верным для каждого случая.

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

На самом деле мы передаем наш 4-х битный код, в виде импульса строго определенной длинны, собственно "код" и определяет его длину. Ответ так же получаем импульсом. И отклонение длинны этого импульса более чем на 2% во времени даст нам уже либо "другой код" (а это провал) либо вообще не валидный код из запрещенного диапазона — а это со стороны основного процессора сразу без вопросов — сброс. Так что кварцу мы тоже теперь доверять можем… По крайней мере, если для 2-х кварцев в 5 сантиметрах друг от друга какие то одинаковые физические воздействия не приведут к строго одинаковому дрейфу их частоты… А какие воздействия? ну не знаю. Атомный взрыв например. Можем ли мы доверять системе в условиях когда в непосредственной близости атомный взрыв?! Конечно нет… ведь никаких "нас" там уже нет.

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

Что можно почитать про инциденту c тойотой (не содержит бреда, эмоций, фантазий и домыслов):
1) ETCSi_Report_Sept242012.pdf
2) nhtsa.gov/staticfiles/nvs…f/NASA_report_execsum.pdf

Ну а вас поздравляю с новым годом. Увидимся в 2020.

P.S.
Есть такие коробочки — обманки на педаль.
Когда вы чуть нажимаете педаль коробочка на некоторое время формирует 100%-но валидный по обоим каналам датчиков положения педали сигнал о том, что педаль нажата в пол…
А потом через некоторое время она возвращает его к норме…
Каждый раз когда вы прикоснулись к педали она делает это…
и каждый раз через некоторое время обратно возвращает…
Приятных снов…

Продолжение — видео-дополнение к части 4.