roboforum.ru

Виталий писал(а):Принципиальная проблема в том, что зачастую отключение одного модуля ведет к веерному отключению других, что делает систему неработоспособной.

Ну дык это IMHO как написать в целом то у них сервисы независимо работают и запросы на запуск\останов сервисов можно через какой-то спец-сервис делать, и у него же спрашивать - работает какой-то сервис или нет.

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

Если будет время на этих выходных, то составлю план ядра системы. Нужно хитрым образом вплести туда пункт "мотивации".

Виталий писал(а):Я все это понимаю, но дело в том, что в сложной системе отключение модуля приводит к останову всей системы. Как ни напиши.

Сервер - сложная система? Горячая замена дисков - отключение модуля? Система останавливается вся?

Ещё смена памяти, БП и почти всего остального без останова системы...

Сервер - сложная система?

Нет.
Но пример рассмотрим. Мы можем отключить диск только в том случае, когда он не нужен для работы системы в данный конкретный момент времени. В роботе скорее всего таких частей не будет.
Например фирма Siemens в свое время отказалась от работы в области авиации, но продолжила в области создания локомотивов для железных дорог. Основная причина - отсутствие в авиации особого состояния "safety stop". Об этом я и говорил.

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

Мы можем отключить диск в зависимости от режима работы массива и его избыточности...
(я админом был 10 лет назад...)

Виталий писал(а):

Сервер - сложная система?

Нет.

Зашибись, тогда давай пример сложной системы.

Виталий писал(а):Но пример рассмотрим. Мы можем отключить диск только в том случае, когда он не нужен для работы системы в данный конкретный момент времени. В роботе скорее всего таких частей не будет.

Неожиданное допущение. По моему это конкретное осознанное решение - делать любой сложности систему отказоустойчивой или нет. Можно сделать сервер неотказоустойчивый, в котором всего 1 винт и его нельзя выдергивать, а можно сделать Интернет с огромным количеством серверов, связей и т.п. который не умрёт, если не вывести из строя существенное количество ключевых серверов.

Виталий писал(а):Я не буду спорить о сложности систем, скажу лишь, что сложность для меня определяется количеством и неоднородностью связей.

Дык давай пример хотябы, спорить пока никто и не начинал?

По поводу интернета не уверен в надежности т.к. метеорит в диаметре 150 км выведет большинство серверов...

Мы можем отключить диск в зависимости от режима работы массива и его избыточности...

Именно, т.е. за ненадобностью на некоторое время.

Неожиданное допущение. По моему это конкретное осознанное решение - делать любой сложности систему отказоустойчивой или нет.

Да, конечно ты прав, в том, что это конкретное осознанное решение. В то же время отказоустойчивость программной системы - вещь очень интересная, с одним немаловажным вопросом: кто будет сторожить сторожа? Иными словами, кто (что) будет контролировать того, кто управляет отказами?

Дык давай пример хотябы, спорить пока никто и не начинал?

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

О! Начали с перечисления библиотек к некой виртуальной системе, а скатились до ее устойчивости. Можно ведь просто объявить, что система не убиваемая и допускает "горячую" замену/отключение любого из модулей без потери работоспособности.
Не бум ограничивать полет фантазии мелкими реальными заморочками

RoboTok писал(а):Ещё смена памяти, БП и почти всего остального без останова системы...

Легко, если использовать виртуальные серверы Они позволяют мигрировать без прекращения работы сервера (vmware esx server) - rulezz

Добавлено спустя 2 минуты 16 секунд:
Да и еще, народ а зачем изобретать велосипед? Зачем писать свой шедулер? Почему нельзя взять уже готовый: ядро linux/qnx/linux_rtos(нужное подчеркнуть) и заставить его работать с вашими приложениями.

Придумать мы можем любую систему, в т.ч. и с использованием готовых операционок под МК. Можем и резервное питание игрушечного бота предусмотреть и еще что-нибудь бесполезное. Все это хорошо пока не нужно воплощать все эти излишества в ПО или железе

..., а скатились до ее устойчивости.

Пока еще нет, но это последний и самый суровый аргумент объективной реальности данной нам в ощущениях.
Но еще раз хочется повторить, что это существенно лишь для системы для которой ее динамические характеристики - не играют такой роли, например для робота-игрушки.

Все это хорошо пока не нужно воплощать все эти излишества в ПО или железе.

Согласен.

Ну так а чо трепаться то? Надо писать ТЗ и делать железку\софт В чем сложности? В этой теме привести описание задачи что должны обеспечивать библиотеки. А то как обычно всё куда-то скатится и цель темы уйдет в небытие