The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Для ядра Linux предложена возможность отслеживания переохлаждения системы"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Заметили полезную информацию ? Пожалуйста добавьте в FAQ на WIKI.
. "Для ядра Linux предложена возможность отслеживания переохлаж..." +/
Сообщение от Аноним (125), 18-Дек-23, 15:50 
> Я бы подобное не рискнул делать, если бы мне была поставлена подобная
> задача с хотя бы минимальной но ответственностью

Вообще - работает. Стабильно. Годами. Но если вопрос в том что кто-то умрет или пострадает, многоуровневые защиты - мастхэв, конечно.

> Скорее всего, сделал бы термодатчик или несколько + ОУ / Компаратор +

С этим всем тоже можно познать горя. Заметив что оно нестабильное, неточное, требует мануальную настройку (антитехнологично), нельзя изменить настройки в рантайме, нельзя автоматизировать калибровку "конкретного экземпляра".

Решаемо, но прецизионные, термо и долговременно стабильные компоненты, их взаимодействия в широком диапазоне - это отдельный топик. Дорогой, сложный в покупке, в реализации, с более 9000 залетов. Как минимальный failsafe - почему нет? Как основной loop - блин, у него даже самодиагностики нету. И мы узнаем что FAIL - уже по факту. Круто, современно...

> Нагреватель +
> Несколько последовательно включенных термореле( уже от перегрева и расставленных в разных
> точках )

Термореле не особо надежные, точные и стабильные штуки в общем случае. По цене самолета что угодно, конечно, есть. Как дубовый failsafe - да, но если запас "вниз", будут ложняки. А если вверх - шанс что система испечется до отрубания.

С другой стороны - МК около бакса. И LM75 (или его клоны) - цифровой, i2c/smbus, точность градус или лучше. И оно с фабы калиброваное. И может и цепь проверить, и датчики, и что система реагирует на ихменения ожидаемо, и хосту отрепортить статус, и вообще все в safe state уложить. При том кто сказал что safe state всегда решаем компаратором? Возможно для входа в safe state системы надо какое-то секвенсирование действий?

> Ну в том и прикол, что "решение" из статьи позволяет прогревать лишь
> проц, а не в принципе решает проблему

Это конечно зависит от конкретики реализации - но тепло проца чаще всего рассеивается в тот же объем и стало быть подогреет его.

> Линь вообще на пушечный выстрел не подпускают к автоматике любые кому хоть
> что-то дорого( включая карму и лицензии в зависимости от страны )

Поэтому он летает в космос, рулит поездами, промом, а вот это хотят - автомотивщики. Логично.

> Он( нередко с кутями ), по сути, служит лишь "мордой" к контроллеру,

У элонмасковского корабля он - таки - бортовой компьютер, вот. Конечно их несколько, и контроллеры подстраховывают, но...

> в котором зашита ОСРВ повышенной надёжности с кучей задач

Взаимоисключающие параграфы - "куча задач" не способствует "повышенной надежности". В этом случае чем фирмвар МК тупее - тем меньше там места для лажи. А если там куча задач... при том еще и не факт что вы и те индусы - програмите лучше вон тех из кернела.

> и которая корректно отработает даже если линь зависнет или упадёт

И тем не менее даже я заимплементил системы которые годами работают. Ничего там не виснет и не падает. Надо просто вынуть руки из... и научиться в валидацию системы ДО того как ее отдать другим.

> Знают. Греет хорошо, но охлаждает - почти никак и с риском уже их перегреть

У них есть свои лимиты применимости. Зато - мелкие и электрчиески управляемые. Там фэйл в лимитированом числе включений еще. Видимо от перепадов кучаконтактов PN junction может отвалиться уже там :). И если вы будете вот именно компаратором его рулить - он и помрет в момент, лимит на число включений даже в даташите бывает. Но если вместо тупого компаратора взять PWM, доделать до DCDC (например buck) и вместо on/off - рулить заполнением PWM, а катуха еще и фильтранет пульсации... все станет гораздо оптимистичнее. И придумал DCDC+Firmware не я. Но я тоже уже немнго умею.

> Ещё и классическая с полупроводниками штука - что параметры со временем плывут и сильно

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

p.s. долбаный бот, чего ему в вон том сообщении не нравится?

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Для ядра Linux предложена возможность отслеживания переохлаждения системы, opennews, 14-Дек-23, 19:57  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру