Почему-то нет этапа разработки тестового стенда, методики испытаний и не выделено время на сами испытания.
Что еще интересней, нет важного вопроса заказчику — как он будет осуществлять приемку продукта и сколько времени.
Сомневаюсь что вменяемый заказчик расскажет правду о своих клиентах и бизнесе, нередко он сам плохо их знает.
Поэтому нет еще одного важного пункта — внедрение избыточности для покрытия рисков ненадежной коммуникации с заказчиком. И это не сроки.
Да, и CAN-у в проекте уделено слишком много внимания, это плохой признак в отношении исполнителя.
Ну все к тому и пришло.
«Технический долг» — эвфемизм фразы «вы виноваты».
Т.е. виноваты простыне кодеры, поскольку превысили цикломатичность и все такое.
Причем граница для всех критериев «долга» выбирается эмпирически, как пишут сами авторы этого набора критериев.
Хочешь усилить чувство вины молодых кодеров — опусти границу цикломатичности.
При этом избегается тема получения единой оценки долга, т.е. агрегирования оценок по всем критериям и получения единственного числа, а главное определение справедливой границы.
Отличный инструмент психологического давления.
Ну тогда что такое идеальная жизнь, и когда она взыскивает, а когда бьет ни за что?
Не стоит ли говорить просто о фитбэке (обратной свзи) и подойти к проблеме с точки зрения теории управления и фильтрации и не мистического долга перед жизнью.
Технический долг — метафора. А статья предлагает метафоры к метафоре.
Кто нибудь объяснит о чем все таки речь?
Если это действительно долг, то почему его не взыскивают через суд?
Если это просто не идеальный код, то где доказательства что идеальный код существует?
Словом как количественно оценить этот долг если он объективно существует как явление, а не как субъективное ощущение?
Embarcadero славен своими компонетами, а не сам по себе.
И писать в нем стоит на Delphi, а не на C++, поскольку все самые ходовые компоненты компоненты и сам фреймворк VCL написаны на Delphi.
Используя C++ теряется доступ к отладке библиотек в своем приложении.
Что самое замечательное, компоненты Delphi и сам VCL все в исходниках, всегда доступен дебагинг на уровне ассемблера.
Для мультиплатформенного программирования Embarcadero явно слабоват если вообще юзабелен, это точно.
Но десктопные приложения под Windows в нем выходят очень крутые, но естественно только при использовании сторонних компонентов. Для успешной работы нужен набор из пары десятков сторонних пакетов компонентов.
Кто начал в Embarcadero недавно могут даже и не сориентироваться что стоит ставить, а что нет, поскольку дело очень затратное по времени, а сам Embarcadero в своей палитре предлагает весьма бедный и ограниченный набор.
У меня занимает 11 Gb из них: 3.5 Gb либы андроида, 1 Gb либы линукса, 3.5 либы Windows для 32 и 64 отдельно. Сами файлы IDE там от силы 3 Gb занимают.
Все что выше будет platform SDK.
Visual Studio качает такие же самые SDK.
Кстати, если держать вместе и RAD Studio и Visual Studio, то можно сэкономить место заставив их использовать SDK из единой директории.
Это совсем не то.
Выж не для bare metal генерите код.
У вас там QNX где-то проскакивает. Короче RTOS.
В вашей модели вообще не видно сервисов RTOS, где контроль реального времени?
Или надежда но то что все процессы достаточно медленные?
Эт одна из проблем вашей модели.
Другая проблема в программных интерфейсах модели и платформы на которую она переносится. Здесь не проработано. Модель строится с учетом доступных программных интерфейсов если она предусматривает генерацию рабочего кода.
Далее масштаб времени. Не видно других моделей более низкого и более высокого уровня в масштабе времени.
Где детализованные модели клапанов? Или надежда на готовые библиотечные элементы. Опасное упрощение.
Словом представленная вами модель — это такой эскиз. По нему можно в принципе проектировать архитектуру софта некоторого уровня абстракции, но сгенерить достаточно робастный и рабочий код — нет.
Тут надо бы признаться, что модель не полная и запускать программу отлаженную на такой модели сразу в поле нельзя.
Модель только лишь для того чтобы автоматизировать некоторые тестовые воздействия на программу, и то не все, а только самые базовые.
В этой теме самое интересное это автогенерация кода. Какой он получается и насколько сложно его интегрировать в уже имеющуюся платформу.
Так это и есть Angle Tracking Observer.
Назвать это моделью датчика крайне неуместно. Этот обсервер всего лишь рациональная функция для сходимости итерационного процесса минимизации ошибки.
Функция обсервера тюнингируется. Т.е. подбирается методом тыка, что говорит об отсутствии знаний о реальной модели.
В чипах ресолверов от TI, AD применяются некие способы демодуляции, но не модели.
Может вы имеете в виду Angle Tracking Observer в демодуляторах?
Но в статье говориться о прямой подаче синуса и косинуса в бортовой компьютер.
О каких синусах с косинусами тогда идет речь?
Ага, и включить в мозгу несколько десятков контуров управления.
Человек с одним контуром плохо справляется: скорость — педаль газа.
Нет, проблема в переоценке надежности датчика AoA. А надежность — это цена.
В технике широко применяется понятие риска — произведение вероятности катастрофы на стоимость катастрофы в количестве человеческих жизней.
Как не цинично, но может оказаться, что две последние катастрофы для Боинга не подняли планку риска с учетом предыдущей истории, о они соответственно не предпримут никаких кардинальных мер.
Внутренней моделью поведения для такого датчика была бы модель самолета.
Что, естественно, нереально.
Но вот простые фильтры там наверняка стоят.
Не факт, что в этих датчиках используются классические СКВТ. Датчики выдают 4-е разных типа сигналов. Либо это разные версии, либо там процессор конвертирующий интерфейсы.
А физическим датчиком может быть и емкостная схема как тут — www.cui.com/product-spotlight/capacitive-absolute-encoders-amt20-series
Странно что автор анализирую датчик Model 0861 AOA Transmitter не упоминает еще Model 0020 Electronic Signal Conditioning Module.
Как понимаю, сигналы прямо с 0861 не могли идти непосредственно в Air Data and Inertial Reference Unit, ADIRU или в Stall Management and Yaw Damper, SMYD. Их как минимум надо фильтровать, усиливать или аттенюировать, масштабировать и проч. Ведь системы типа ADIRU наверняка не проектируются под конкретный датчик третьей фирмы.
Для этого есть вещи типа Model 0020, которые сигналы датчиков приводят к стандартному виду для систем более высокого ранга.
И вот в этой Model 0020 собака скорее всего и порылась, начиная с того что там мог просто отключится регулятор подогрева, и кончая тем что там возможно тоже не стояло опции самотестирования.
В ABS на сидящей на полевой шине может быть один процессор коммуникационный, один основной и один на приеме и предобработке сигналов, у каждого своя RTOS. Однопроцессорные решения давно в прошлом.
Даже в простейших модуля ввода-вывода ПЛК стоит по три процессора.
Поэтому когда говорят о RTOS надо сужать их применение до сверхлокальных задач.
Какие там заводы или автомобили. Отдельные лампочки, моторчики или даже просто контакторы — вот ниша настоящих RTOS.
Да, мое определение -> 1+-0.1 мкс
Оно сразу отсекает CPU с многоуровневыми кэшами, MMU, всякие малинки с линуксами, Windows-ы и прочие OS-ы и процессоры приложений.
Не то что бы такое определение было всегда, а только теперь оно кристаллизуется, когда ARM стал делать ядра заточенные под RTOS.
На малинке можно добиться реального времени, но не с RTOS, а с маленькой стэйт машиной влезающей в его кэш.
Так же и c PC.
Я говорю о современном реальном времени, т.е. 1 мкс на переключение задач с соответствующим детерминизмом.
Говорю же, забазируйтесь на абсолютнов времени и все станет яснее.
За образец держите ThreadX.
Кстати странно почему ее игнорируете, она ж даже в малике есть.
Ну так это определение же ставит вас в тупик в который вас тут все время направляют.
Вон в MATLAB есть десктопный движок с временем гарантированного отклика в 1 мс.
Будем считать теперь Windows Home Edition является RTOS?
Для управления заводами не нужна RTOS, для управления современным автомобилем тоже. Это гетерогенные системы, в их масштабе об одной RTOS говорить бессмысленно. Нужно четче обрисовывать область применения RTOS.
О RTOS можно говорить только в контексте современных технологических рубежей.
И эти рубежи можно описать цифрами.
Я дал оценку этих цифр исходя из своего опыта.
У процессора с 1 ГГц будет многоуровневый кэш и о детерминированности в 0.1 мкс в этом случае говорить не приходится.
Есть процессоры с TСM на 600 МГц, там соответственно время переключения не должно превышать 0.5 мкс (учтем занятость шин DMA и прочие издержки)
А все потому что вы ушли от рассмотрения времени в RTOS.
Поставьте критерием время переключения контекста любой задачи в 1 мкс на 100 МГц процессоре с float-point сопроцессором с детерминированностью в 0.1 мкс и все станет на свои места.
Вы четко увидите где RTOS, а где нет.
Что еще интересней, нет важного вопроса заказчику — как он будет осуществлять приемку продукта и сколько времени.
Сомневаюсь что вменяемый заказчик расскажет правду о своих клиентах и бизнесе, нередко он сам плохо их знает.
Поэтому нет еще одного важного пункта — внедрение избыточности для покрытия рисков ненадежной коммуникации с заказчиком. И это не сроки.
Да, и CAN-у в проекте уделено слишком много внимания, это плохой признак в отношении исполнителя.
«Технический долг» — эвфемизм фразы «вы виноваты».
Т.е. виноваты простыне кодеры, поскольку превысили цикломатичность и все такое.
Причем граница для всех критериев «долга» выбирается эмпирически, как пишут сами авторы этого набора критериев.
Хочешь усилить чувство вины молодых кодеров — опусти границу цикломатичности.
При этом избегается тема получения единой оценки долга, т.е. агрегирования оценок по всем критериям и получения единственного числа, а главное определение справедливой границы.
Отличный инструмент психологического давления.
Не стоит ли говорить просто о фитбэке (обратной свзи) и подойти к проблеме с точки зрения теории управления и фильтрации и не мистического долга перед жизнью.
Кто нибудь объяснит о чем все таки речь?
Если это действительно долг, то почему его не взыскивают через суд?
Если это просто не идеальный код, то где доказательства что идеальный код существует?
Словом как количественно оценить этот долг если он объективно существует как явление, а не как субъективное ощущение?
И писать в нем стоит на Delphi, а не на C++, поскольку все самые ходовые компоненты компоненты и сам фреймворк VCL написаны на Delphi.
Используя C++ теряется доступ к отладке библиотек в своем приложении.
Что самое замечательное, компоненты Delphi и сам VCL все в исходниках, всегда доступен дебагинг на уровне ассемблера.
Для мультиплатформенного программирования Embarcadero явно слабоват если вообще юзабелен, это точно.
Но десктопные приложения под Windows в нем выходят очень крутые, но естественно только при использовании сторонних компонентов. Для успешной работы нужен набор из пары десятков сторонних пакетов компонентов.
Кто начал в Embarcadero недавно могут даже и не сориентироваться что стоит ставить, а что нет, поскольку дело очень затратное по времени, а сам Embarcadero в своей палитре предлагает весьма бедный и ограниченный набор.
Все что выше будет platform SDK.
Visual Studio качает такие же самые SDK.
Кстати, если держать вместе и RAD Studio и Visual Studio, то можно сэкономить место заставив их использовать SDK из единой директории.
Выж не для bare metal генерите код.
У вас там QNX где-то проскакивает. Короче RTOS.
В вашей модели вообще не видно сервисов RTOS, где контроль реального времени?
Или надежда но то что все процессы достаточно медленные?
Эт одна из проблем вашей модели.
Другая проблема в программных интерфейсах модели и платформы на которую она переносится. Здесь не проработано. Модель строится с учетом доступных программных интерфейсов если она предусматривает генерацию рабочего кода.
Далее масштаб времени. Не видно других моделей более низкого и более высокого уровня в масштабе времени.
Где детализованные модели клапанов? Или надежда на готовые библиотечные элементы. Опасное упрощение.
Словом представленная вами модель — это такой эскиз. По нему можно в принципе проектировать архитектуру софта некоторого уровня абстракции, но сгенерить достаточно робастный и рабочий код — нет.
Модель только лишь для того чтобы автоматизировать некоторые тестовые воздействия на программу, и то не все, а только самые базовые.
В этой теме самое интересное это автогенерация кода. Какой он получается и насколько сложно его интегрировать в уже имеющуюся платформу.
Назвать это моделью датчика крайне неуместно. Этот обсервер всего лишь рациональная функция для сходимости итерационного процесса минимизации ошибки.
Функция обсервера тюнингируется. Т.е. подбирается методом тыка, что говорит об отсутствии знаний о реальной модели.
Может вы имеете в виду Angle Tracking Observer в демодуляторах?
Но в статье говориться о прямой подаче синуса и косинуса в бортовой компьютер.
О каких синусах с косинусами тогда идет речь?
Человек с одним контуром плохо справляется: скорость — педаль газа.
Нет, проблема в переоценке надежности датчика AoA. А надежность — это цена.
В технике широко применяется понятие риска — произведение вероятности катастрофы на стоимость катастрофы в количестве человеческих жизней.
Как не цинично, но может оказаться, что две последние катастрофы для Боинга не подняли планку риска с учетом предыдущей истории, о они соответственно не предпримут никаких кардинальных мер.
Что, естественно, нереально.
Но вот простые фильтры там наверняка стоят.
Не факт, что в этих датчиках используются классические СКВТ. Датчики выдают 4-е разных типа сигналов. Либо это разные версии, либо там процессор конвертирующий интерфейсы.
А физическим датчиком может быть и емкостная схема как тут — www.cui.com/product-spotlight/capacitive-absolute-encoders-amt20-series
Как понимаю, сигналы прямо с 0861 не могли идти непосредственно в Air Data and Inertial Reference Unit, ADIRU или в Stall Management and Yaw Damper, SMYD. Их как минимум надо фильтровать, усиливать или аттенюировать, масштабировать и проч. Ведь системы типа ADIRU наверняка не проектируются под конкретный датчик третьей фирмы.
Для этого есть вещи типа Model 0020, которые сигналы датчиков приводят к стандартному виду для систем более высокого ранга.
И вот в этой Model 0020 собака скорее всего и порылась, начиная с того что там мог просто отключится регулятор подогрева, и кончая тем что там возможно тоже не стояло опции самотестирования.
Даже в простейших модуля ввода-вывода ПЛК стоит по три процессора.
Поэтому когда говорят о RTOS надо сужать их применение до сверхлокальных задач.
Какие там заводы или автомобили. Отдельные лампочки, моторчики или даже просто контакторы — вот ниша настоящих RTOS.
Оно сразу отсекает CPU с многоуровневыми кэшами, MMU, всякие малинки с линуксами, Windows-ы и прочие OS-ы и процессоры приложений.
Не то что бы такое определение было всегда, а только теперь оно кристаллизуется, когда ARM стал делать ядра заточенные под RTOS.
Так же и c PC.
Я говорю о современном реальном времени, т.е. 1 мкс на переключение задач с соответствующим детерминизмом.
Говорю же, забазируйтесь на абсолютнов времени и все станет яснее.
За образец держите ThreadX.
Кстати странно почему ее игнорируете, она ж даже в малике есть.
Вон в MATLAB есть десктопный движок с временем гарантированного отклика в 1 мс.
Будем считать теперь Windows Home Edition является RTOS?
Для управления заводами не нужна RTOS, для управления современным автомобилем тоже. Это гетерогенные системы, в их масштабе об одной RTOS говорить бессмысленно. Нужно четче обрисовывать область применения RTOS.
О RTOS можно говорить только в контексте современных технологических рубежей.
И эти рубежи можно описать цифрами.
Я дал оценку этих цифр исходя из своего опыта.
У процессора с 1 ГГц будет многоуровневый кэш и о детерминированности в 0.1 мкс в этом случае говорить не приходится.
Есть процессоры с TСM на 600 МГц, там соответственно время переключения не должно превышать 0.5 мкс (учтем занятость шин DMA и прочие издержки)
Поставьте критерием время переключения контекста любой задачи в 1 мкс на 100 МГц процессоре с float-point сопроцессором с детерминированностью в 0.1 мкс и все станет на свои места.
Вы четко увидите где RTOS, а где нет.
Без документации система не юзабельна.