Кстати, интересно, как оно работает. Если есть опыт, расскажите (можно, отдельной статьей).

Мне как-то довелось поработать не с АЭС, но с космосом. Тройное дублирование тоже используют. А мега-надёжное аппаратное мажорирующее устройство состоит из 5 транзисторов. :)

Со станцией это я загнул :) Насколько мне известно. там используют тройное дублирование с мега-надежным аппаратным мажорирующим устройством.

Если говорить об атомных станциях, то обычно постулируется, что система надёжно (ровно 100%) диагностирует один отказ (или два, три…). В данном случае это не так. Так что перед включением сервопривода вывода стержней из активной зоны стоит проверить сумму хотя бы ещё раз =)

Зависит от того, как повредится и в каком месте эта процедура находится :)

Во-первых, при перепрошивке целостность обычно контролирует неперепрошиваемый бутлоадер, вероятность что в нем что-то повредится резко меньше, чем в прошиваемом коде.

Единственное место в процедуре контроля, в котором повреждение критично — инструкция проверки if'a (повреждение во всех остальных местах приведет к правильной ветке if'а). Инструкция сравнения занимает 4 байта (может и 2, лень искать). Пусть прошивка — 64кБайта. Если просто поделить одно на другое, то вероятность пропустить ошибку — 0.006%. Думается мне, что в реальности вероятность будет на порядок больше, но это намного лучше, чем ничего.

Что будет, если повредится процедура контроля прошивки?

Ух ты! Спасибо огроменное за ссылки! Только сейчас их увидел, посмотрел пару — просто офигенная подача материала. Наконец-то я смогу понять чему меня учили десять лет назад. Реально очень доходчиво объясняют.

Пока нет :) Другие неотложные дела.

Ну, как там разводка, продвигается?:)

Поправил статью, а то тупо выглядит :)

Да? :) Не знал. Ну тогда эта заметка будет для таких как я :)

Поэтому придумал велосипед свой способ.

Вообще-то, это штатный способ организации многоплатных проектов :)

Про масштаб я понимаю, конечно, но статистические методы нужны для исследования, а применять их можно и в маленьких масштабах.

Согласен, что пример плохой, я описывал методы :)

Если задача развиться до «правильной» экономики не стоит, то да можно это все и не учитывать. Но если конечная цель — выйти на правильную рыночную модель, то ее нужно начинать внедрять и оттачивать с самого начала.

поиграться в мега-корпорацию

А я пытаюсь доказать, что для вашего случая эти теории неприменимы! Экономические закономерности, которыми вы пытаетесь оперировать, верны «в среднем», когда работает закон больших чисел. У вас же — единичные, ручные продажи и индивидуальное ценообразование. Не все покупатели выбирают оптимальные решения, кто-то делает импульсивные покупки, кого-то (в принципе) можно обмануть и он заплатит втридорога. Нельзя считать этих покупателей показательными, чтобы строить вероятностные модели и делать прогнозы. Понимаете, о чем я? Не работает здесь экономика…

Я говорю, что разработчик UTC4 — НЕ корпорация

Ну, поиграться в мега-корпорацию то можно, не смотря на суровую реальность :)

график для вашей ситуации вполне может оказаться такого вида:

На вашем графике изображены две группы людей — одни готовы платить много, но их мало. Другие готовы платить мало, но их много.

Если назначить цену где-то посередине, то все, кто готов был платить много товар купят и некая часть тех, которые готовы были платить мало купит. В итоге, график будет выпуклым. Для того, чтобы график имел перегибы, должен быть очень большой разрыв между этими двумя категориями людей. В случае с таким большим разрывом неплохо бы сделать два продукта под две ниши. Тут примерно как с запорожцем и феррари.

Конечно, ситуация с локальными экстремумами возможна, но, кажется, очень маловероятна.

Это вы сейчас про яблочную компанию?

Наоборот. Я говорю, что разработчик UTC4 — НЕ корпорация, он продает единичные устройства, и «классические» законы экономики для него не работают. Приведенный классический график для вашей ситуации вполне может оказаться такого вида:


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

Есть конкретный разработчик, который уважает себя и ценит свой труд.

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

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

Про оценку товаров по внутренним ощущениям я говорил в «циганском методе». Для того, чтобы оценить товар ориентируясь на некие внутренние ощущения, нужно эти самые ощущения иметь. У меня навык оценки цены очень плохо развит, и мои ощущения могут очень сильно промазать, поэтому проще применить некую формальную методику, так будет намного лучше.

И не может быть идеальной цены!

Вот тут я очень не согласен, тут можно вспомнить экономику. Идеальная цена — это такая, которая обеспечивает максимальную общую вырчку (TR в экономике). Вот классический график зависимости выручки от цены (P — цена). Как видно, есть совершенно четкая точка идеальной цены.

Мое скромное мнение, что не стоит усложнять. Пока вы не корпорация, вам не нужно изучать американский маркетинговый бред и все эти коэффициенты.

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

Вопрос не в цене даже, а в том, насколько разработчик сам себя уважает. Если НЕ уважает, то будет подстраиваться под рынок, будет завистливо подглядывать за конкурентами, мониторить колебания цен и пытаться мелочно выжать каждую дополнительную копейку. А если уважает, то будет САМ диктовать рынку свои условия.

Нагрев, как и у всех линейников определяется падением и током. У меня токи мизерные, поэтому и полигонов нет вообще.