Аннотация
Charles Shelton, Philip Koopman Разработка архитектуры программного обеспечения для плавного торможения в системе управления лифтом. В статье рассмотрена аръитектура программного обеспечения для плавного торможения в системе управления лифтом.
Введение
Лифт является сложной распределенной системой управления. Это и определяет строгие требования к безопасности: он не может передвигаться на опасных скоростях в шахте лифта; и он не должен оставить людей в ловушке в лифте.
Мы используем модель лифтовой системы, основанную на множестве датчиков и исполнительных механизмов. Эта система не учитывает некоторые более сложные лифтовые функции, такие как режимы работы как быстрый
режим реагирования, режимы технического обслуживания.
Лифт
Лифт состоит из целой машины в шахте лифта с доступом к определенному количеству этажей. Машина имеет одну дверь и дверной двигатель, привод, который позволяет разогнать машину до двух скоростей (быстрые и медленные) в шахте, и аварийные тормоза для безопасности. В приведенной ниже записи, значения в рамках проекта [ ]
скобки обозначают стандартную репликацию из массива датчиков или исполнительных механизмов, а также значении в ()
скобки представляют значения датчиков или может выводить значение силового привода.
Например, датчик AtFloor является массивом датчиков f – что соответствует количеству этажей, которые обслуживает лифт, d – направление в котором лифт собирается ехать: вверх, вниз, или Стоп в ширину, где каждый элемент массива может быть определен по значению v – правда или ложь. Когда лифт приближается к этажу f, он может ехать вверх либо вниз, так как есть AtFloor датчик на каждом этаже, для того чтобы указать на каком этаже находится машина и в каком направлении едет. Когда лифт достаточно близко к датчику AtFloor датчик срабатывает.
Датчики доступные в системе включают в себя:
AtFloor[f,d](v) напольный датчик f = этаж, d = [Вверх Вниз Стоп], v = [Правда Ложь],
CarCall[f](v) этажные кнопки f = этаж, v = [Правда Ложь]. Все расположены внутри кабины лифта.
DoorClosed (v) закрытия дверей v = [Правда Ложь]. Указывает Правда, когда дверь полностью закрыта.
DoorOpen (v) открытия дверей v = [Правда Ложь]. Указывает Правда, когда дверь полностью открыта.
DoorReversal (V) датчик изменения состояния дверей (на случай помехи в дверном проеме лифта), v =[Правда Ложь]. Указывает Правда, когда дверь полностью открыта.
HallCall[f,d](b) Кнопки вызова на этажах. f = этаж, d = [Вверх Вниз], b = [Нажатие Режим ожидания]
HoistwayLimit[d](v) Безопасные концевые выключатели шахты d = [Вверх Вниз Стоп], v = [Правда Ложь]. Указывает Правда, когда лифт на верхнем либо нижнем этаже.
DriveSpeed(s,d). Датчик скорости на главном приводе. s = [Быстро Медленно Остановка], d = [Вверх Вниз Стоп].
Приводы системы:
DoorMotor(m) Дверь двигателя. m = [Открыть Закрыть Остановка]
Drive(s,d) Главный двухскоростной привод. s = [Быстро Медленно Стоп], d = [Вверх Вниз Стоп]
CarLantern[d](k) Подсветка на дверной раме. d = [Вверх Вниз] k = [Включено Выключено] Используются пассажирами для удобства.
CarLight[f](k) Подсветка кнопок вызова. f = этаж, k = [Включено Выключено] Для определения выбранного этажа.
CarPositionIndicator(f) Индикатор текущего положения лифта. f = floor
EmergencyBrake(b) Аварийная остановка. b = [Включен Выключен]
Это далеко не полное описание современного лифта , но это довольно сложная модель, которая имеет ресурсы, чтобы обеспечивают несколько возможных уровней работы.
Предлагаемая Архитектура программного обеспечения
Необходимо иметь несколько зависимостей между отдельными программными компонентами, особенно для критически важных функций.
Тем не менее, это означает, что каждый программный компонент должен был бы иметь свою собственную прямую связь друг с другом. Датчики и приводы должны делать свою работу, и это маловероятно, что каждая задача в системе потребует только один компонент программного обеспечения без согласования с другим компоненты системы.
Мелкозернистая распределенная система требует, чтобы компоненты работали вместе для выполнения задач, так, чтобы эта работа выполнялась правильно и необходимо сделать переключение компоненты на автономную когда это возможно, или когда функция особенно важна.
Ключевой идеей этой системы управления лифта является архитектура разделов на функциональность системы в критической и некритической ситуации. Мы указываем базовый уровень функциональность в системе , что является наименьшим уровнем операций, перед которыми мя объявляем систему сломанной. Если мы делаем компоненты, которые обрабатывают эти ключевые задачи автономно и очень отказоустойчиво, то мы можем рассматривать дополнительное некритические компоненты и функциональность как усовершенствования к основному набору. Пока эти компоненты не нарушают любое из ограничений основного набора, когда они терпят неудачу – могут быть удалены из системы в то же время, сохраняя по крайней мере базовую функциональность.
Чтобы применить эту идею к нашей модели лифта :лифт на базовом уровне должен быть только в состоянии двигаться между этажами в шахте, открывать и закрывать двери на каждом этаже, и быть уверенным в безопасности пассажиров. Лифт может двигаться медленно в шахте, останавливаясь на каждом этаже забирать и привозить людей, открывать и закрывать двери на каждом этаже, игнорируя все пассажирские запросы, а не предоставлять любому пассажиру обратную связь. Все другие функции в системе; обработка запросов, обеспечивая обратной связь и для пассажиров, остановки только на нужных этажах, для усовершенствования эффективности.
В нашей архитектуре компонентами, которые обеспечивают минимальную функциональность являются управление дверей, управление приводом, и компоненты безопасности (рис. 1).
Рисунок 1 – Важные компоненты в нашей архитектуре программного обеспечения лифта
Обратите внимание, что все они имеют прямой доступ к датчикам, которые они требуют для правильной эксплуатации и не взаимодействуют друг с другом.
Управление дверей должно знать, когда привод движется и когда лифт останавливается на этаже, чтобы определить, когда открыть дверь, поэтому он имеет доступ к соответствующим датчикам. Привод должен знать , когда двери полностью закрыты и когда остановиться на этаже. Он также должен иметь доступ к концевым шахтовым датчикам для внутренних проверок безопасности.
Объект безопасности должны быть в состоянии определить, когда привод и дверь выполняет любые опасные действия, такие как перемещение, когда дверь открыта. Они представляют логические датчики в архитектуре программного обеспечения , поскольку в них могут быть либо несколько каналов ввода / вывода в той же физической системе датчиков, или несколько различных физических датчиков для каждого программного компонента. Этот выбор представляет собой стоимость / надежность, что не влияет на архитектуру программного обеспечения. Компоненты программного обеспечения будут иметь те же интерфейсы к датчикам независимо от физической конфигурации. Тиражирование датчиков для этих критических компонентов будет предотвращением единых точек отказа, которые могут привести к катастрофическим системным сбоям.
Сверх этой базовой конфигурации мы можем добавить в режиме реального времени сеть для связи компонентов и координации. Затем мы добавляем кнопку на этаже и кнопку в лифте для контроллеров, которые будут управлять пользовательским вводом от пассажиров; контроллеры для подсветки кабины лифта и указания положения, контроллер для обратной связи с пользователями; и диспетчерский компонент для планирования эффективного направления кабины лифта (рисунок 2).
Рисунок 2 – Полная схема архитекутры программного обеспечения лифта
С добавлением в режиме реального времени сети, каждому дополнительному компоненту не нужно прямое подключение к каждому датчику.
Если некритические компонент выходит из строя он не должен мешать работе любого критического компонента или, в идеале, ни один из других некритических компонентов не должен этого ощутить. Стандартное предположение, что эти компоненты должны прекратить отправку сообщений.
Одна из основных проблем в реализации этой схемы в том, как убедиться, что некритическое компоненты не нарушают ограничения критического ядра компонент. Наш подход заключается в определении плотного интерфейса в форме четко определенного набора данных, которые могут быть отправлены между компонентами, и обеспечат, чтобы тех пор, пока компоненты придерживаются этого интерфейса, будут сохраняться ограничения.
Выводы
Архитектура программного обеспечения, описанная выше, имеет несколько
свойств, которые должны обеспечить расширения и к другим типам систем. Основные подходы, стоящие за этой архитектурой: определение базового набора с минимальной функциональностью, который определяет рабочую операцию; действия компонент, которые обрабатывают эту базовую функциональность как автономную и отказоустойчивую, насколько это возможно; обеспечение того, чтобы интерфейсы между компонентами были четко определены и не нарушали внутренние ограничения компонентов. Сейчас мы разрабатываем архитектуру для этой системы управления в симуляции, и проводим исследование, как моделировать отказы.
Литература:
- [Bass98] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, Addison–Wesley, Reading, MA, 1998.
- [Herlihy91] M. Herlihy, J. Wing,
Specifying Graceful Degradation,
IEEE Transactions on Parallel and Distributed Systems, 2(1):93–104, January 1991. - [IEEE90] IEEE Standard Glossary of Software Engineering Terminology (IEEE Std610.12-1990), IEEE Computer Soc., Dec. 10, 1990.
- [Nace2000] W. Nace, P. Koopman,
A Product Family Approach to Graceful Degradation,
9 DIPES 2000, Paderborn, Germany, October 8–19, 2000