Меню
Главная
Авторизация/Регистрация
 
Главная arrow Техника arrow Информационные технологии в технической эксплуатации автомобилей

Диаграммы системы технической эксплуатации

Диаграмма вариантов использования отражает концептуальную модель системы TEA и описывает функциональное назначение системы, а как "актер" здесь выступает виртуальная ИТС (рис. 3.11), которая согласно работам, выполняет в процессе своего функционирования следующие общие функции:

- Контроль PC технический;

- Контроль потери горючего и др. материалов;

- Контроль процессов КЭ;

- Формирование отчетных рапортов и другой документации по ЖЦ процесса эксплуатации PC;

- Др. функции.

Диаграмма вариантов использования

Рис. 3.11. Диаграмма вариантов использования

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

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

В соответствии с анализом статики, на АТЗК необходимо рассмотреть процесс технического контроля PC.

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

- "РС":

- "Трекеры (сканер коммуникатор)";

- " Web -сервер":

- "ИТС";

- "Диспетчер".

"РС" осуществляет перевозки грузов и пассажиров по заданию.

"Трекер" получает сигналы от спутников системы космической радионавигации, определяет географические координаты нахождения РС и фиксирует время получения сигнала, получает информацию с бортовых датчиков и контроллеров систем управления рабочими процессами узлов, агрегатов систем автомобиля, и через заданные промежутки времени с помощью современных средств радиосвязи " связи передает полученную информацию в виде пакетов данных на сервер системы мониторинга. Таким образом он осуществляет сбор, формирование и передачу данных процесса эксплуатации ЖЦ РС.

"Web- сервер" системы мониторинга - компьютер, работающий круглосуточно и постоянно подключен в сеть Internet , принимает информацию с борта РС. сортирует, заранее обрабатывает, хранит и пересылает информацию по запросу "Диспетчеру" через Web - интерфейс или в виде электронных отчетов.

"Диспетчер" на основе данных " Web -серверу", осуществляет анализ деятельности РС, а именно определяет наличие нарушений КЭ (отклонение РС от маршрута или графика). Также "Диспетчер" следит за выполнением графиков ТО и Р, причинами простоев в ИТС, наличием работников и режимом их работы. Ранее это осуществлялось "Диспетчером" путем непосредственного контроля за бумажными носителями информации, на сегодняшний день невозможно из-за две главные причины:

- Наличие Закона № 8397. который ликвидировал путь письма и лишил ИТС информации о пробегов РС;

- Обслуживание РС на предприятиях ИТС, которые не являются структурными подразделениями комплексных АТП.

Именно через ЦС "Диспетчер" сегодня не в состоянии выполнять свои функции по-ственной мере, что фактически и обусловливает на АТЗК отсутствие технического контроля РС.

Диаграмма классов реальной модели представлена на рис. 3.12.

Класс "РС" связан с классами "Диспетчер" и "ИТС" отношением ассоциации, то есть классы являются равноправными. Класс "РС" связан с классом "Трекер" отношением композиции, а это значит, что на реальном РС установлено телематический устройство - коммуникационный контроллер.

Классы " Web -сервер" и "Трекер" связаны между собой отношением зависимости, то есть некоторое изменение одного из элементов модели требует изменения другого зависимого от него элемента модели. Классы "Диспетчер" и "Web-сервер" также связаны между собой отношением зависимости.

С целью усовершенствования системы технического контроля ЖЦ процесса эксплуатации PC создана виртуальная модель диаграммы классов. В виртуальной модели отсутствует класс "Диспетчер", поскольку сегодня он не имеет возможности в полном объеме выполнять свои задачи. Вместо этого были добавлены классы "Диспетчер ИТС" и "ПО" Virtual mechanic "".

Диаграмма классов.  модель реальная

Рис. 3.12. Диаграмма классов. модель реальная

«Диспетчер ИТС" осуществляет функции, которые были отнесены к классу "Диспетчер", а также возможность проводить оперативный технический контроль и регулирование деятельности PC с помощью класса "ПО" Virtual mechanic "". Класс "ПО " Virtual mechanic "" значительно ускоряет процесс обработки входящей информации и упрощает работу диспетчера ИТС, кроме того он дает возможность работать с точными и важными на сегодняшний день показателями. Графически виртуальная модель диаграммы классов представлена на рис. 3.13.

Класс "Диспетчер ИТС" и "РС" связаны отношением ассоциации, то есть классы являются равноправными. Класс "ИТС" связан с классами "Диспетчер ИТС" и "ПО " Virtual mechanic "" отношением композиции. Класс "ПО" Virtual mechanic "" связан с классом "Диспетчер ИТС" отношением композиции, а с классом "Web- сервер" отношениями зависимости. «Диспетчер ИТС" связан с "вебсервера " отношением зависимости. Логическим продолжением статического анализа системы является динамический анализ системы, который проводится на основе диаграммы последовательности, состояний объекта и системы, деятельности.

На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии. Таковы: "Диспетчер" - он же инициатор взаимодействия, изображается крайней слева, "Web-сервер", "РС", "ИТС". Все объекты на диаграмме последовательности образуют порядок, обусловленный их степени активности.

Диаграмма классов.  модель виртуальная

Рис. 3.13. Диаграмма классов. модель виртуальная

Взаимодействия объектов реализуются с помощью сообщений, которые ссылаются одними объектами другим. Каждое сообщение имеет направление от объекта, который инициирует и отправляет сообщения к объекту, который его получает. Графическое отражение диаграммы последовательности реальной системы представлено на рис. 3.14.

Диаграмма последовательности.  модель реальная

Рис. 3.14. Диаграмма последовательности. модель реальная

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

- 1 - "Диспетчер" приглашает в " Web -сервера" информацию (местоположение, пробег, средняя скорость, время движения, время простоя время нахождения PC в географических зонах)

- 2 - сервер системы мониторинга предоставляет информацию диспетчеру ИТС, которая становится доступной через Web -интерфейс или в виде отчетов формата MS Excel;

- 3 - "Диспетчер" анализирует данные, полученные от сервера, и принимает управленческое решение о деятельности PC;

- 4 - "Диспетчер" дает управленческие команды по плану маршрута, графика движения и др. оперативных действий водителю или владельцу PC в процессе контроля ЖЦ эксплуатации его PC;

- 5 - "РС" обращается в "ИТС" для осуществления действий ТО и Р.

Графически виртуальная модель диаграммы последовательности представлена на рис. 3.15.

Диаграмма последовательности.  модель виртуальная

Рис. 3.15. Диаграмма последовательности. модель виртуальная

Действия, которые выполняются в системе технического контроля в виртуальной модели:

- 1 - "Диспетчер" приглашает в "Web- сервера" необходимую информацию (местоположение, пробег, средняя скорость, время движения, время простоя, время нахождения РС в географических зонах)

- 2 - " Web -сервер" системы мониторинга предоставляет информацию "Диспетчере ИТС", которая становится доступной в виде электронных отчетов

- З - "Диспетчер ИТС" обращается к ПО "Virtual mechanic" для обработки полученных данных;

- 4 - ПО "Virtual mechanic" обрабатывает полученные отчеты, а также проводит следующие действия: проводит оценку параметров состояния парка РС, а именно рассчитывает пробег РС к ТО и трудоемкость действий ТО и Р; определяет вероятность нахождения РС в работе и в ТО и Р, то есть рассчитывает интенсивность входящих заявок на ТО и Р; осуществляет технологический расчет ИТС, определяя пропускную способность ИТС, точки насыщения ИТС, количество постов, необходимых для полноценной работы ИТС, минимальную и оптимальную производительность ИТС; оценивает надежность PC;

- 5 - ПО " Virtual mechanic " предоставляет диспетчеру результаты проведенных расчетов;

- 6 - проанализировав полученную информацию от сервера и ПО, «Диспетчер ИТС" принимает управленческое решение относительно деятельности "РС" и "ИТС";

- 7 - «Диспетчер ИТС" дает управленческие команды "РС" по плану, маршрута, графика движения и др. оперативных действий водителю, владельцу РС в процессе контроля ЖЦ эксплуатации его РС;

- 8 - «Диспетчер ИТС" дает управленческие команды "ИТС" по осуществлению действий по ТО и Р на РС;

- 9 - "ИТС" влияет на "РС" по командам "Диспетчера ИТС".

В виртуальной модели на диаграмме последовательности существует альтернативный поток работы системы в случае обнаружения некорректной работы "Web- сервера". Графически виртуальная модель (поток альтернативный) диаграммы последовательности показана на рис. 3.16.

Диаграмма последовательности.  Модель виртуальная (поток альтернативный)

Рис. 3.16. Диаграмма последовательности. Модель виртуальная (поток альтернативный)

Действия, которые выполняются в системе технического контроля в виртуальной модели альтернативного потока событий, когда обнаружена некорректная работа сервера системы мониторинга:

- 1 - «Диспетчер ИТС" приглашает в "Web- сервера" необходимую информацию (местоположение, пробег, средняя скорость, время движения, время простоя, время нахождения РС в географических зонах) и обнаруживает некорректную работу сервера системы мониторинга;

- 2 - "Диспетчер ИТС" обращается в резервный "Web-сервера", который является составной главного "Web-сервера";

- 3 - "Web-сервер" системы мониторинга предоставляет информацию "Диспетчер ГГС", которая становится доступной через ИРеб-интерфейс, а также в виде электронных отчетов

- 4 - «Диспетчер ГГС" обращается к ПО "Virtual mechanic " для обработки

данных;

- 5 - ПО " Virtual mechanic" обрабатывает полученные отчеты, а также проводит следующие действия: проводит оценку параметров состояния парка PC, а именно рассчитывает пробег PC к ТО и трудоемкость действий ТО и Р, определяет вероятность нахождения PC в работе и в ТО и Р осуществляет технологический расчет ИТС, оценивает надежность PC;

- 6 - ПО " Virtual mechanic " предоставляет "Диспетчеру ИТС" результаты расчетов;

- 7 - проанализировав полученную информацию от " Web-сервера" и ПО " Virtual mechanic", "Диспетчер ИТС" принимает управленческое решение относительно деятельности "РС" и "ГГС";

- 8 - «Диспетчер ИТС" дает управленческие команды РС по плану, маршрута, графика движения и др. оперативных действий водителю или владельцу РС в процессе контроля ЖЦ эксплуатации его РС;

- 9 - «Диспетчер ИТС" дает управленческие команды ИТС по осуществлению действий по ТО и Р на РС;

- 10 - "ИТС" влияет на "РС" в соответствии с командами «Диспетчер ГГС".

Диаграмма состояний и переходов объекта (рис. 3.17) предназначена для описания возможной последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его ЖЦ.

Диаграмма состояний и переходов объекта «Диспетчер ИТС"

Рис. 3.17. Диаграмма состояний и переходов объекта «Диспетчер ИТС"

В качестве объекта выступает «Диспетчер ИТС". Диспетчер в течение своего ЖЦ находится в состоянии процесса проведения технического контроля за деятельностью PC составленный. Данный составленный состояние состоит из двух последовательных составленных состояний: процесса сбора и хранения исходных данных и процесса анализа параметров технического контроля над деятельностью PC, состоящих из последовательных вложенных состояний.

Диаграмма деятельности (рис. 3.18) используется для моделирования процесса выполнения операций.

диаграмма деятельности

Рис. 3.18. диаграмма деятельности

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

Физическое представление системы ТЕА-АСУ и ее особенности описывает диаграмма компонентов. Она позволяет определить архитектуру системы, установив зависимость между программными компонентами. В принятом среде разработки модуль отвечает файла ASU_ControlOJMT.exe (рис. 3.19).

диаграмма компонентов

Рис. 3.19. диаграмма компонентов

Этот компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. В рамках проекта ТЕА- АСУ он является следующим классом: общее описание таких объектов, для которых характерно наличие множества общих особенностей действий и которые могут выполнить эти объекты.

Каждый класс соответствует тем объектам, которые были выделены в рамках функционирования реальной системы:

- «Диспетчер ИТС" ( Class_DispetcherITS ),

- "ИТС" (Class_ITS),

- "Web-сервер" (ClassJVebServe),

- "PC" (Class_TZ),

- "ПО" VirtualMeehan '' (Class_PZ_VirtualMeehan).

Завершает процесс ООП диаграмма развертывания (рис. 3.5). Ее разработка является последним этапом спецификации модели. Она предназначена для визуализации элементов и компонентов программы, которые существуют только на этапе ее выполнения (runtime).

Цели, преследуемые при разработке диаграммы развертывания:

- Определить распределение компонентов системы по ее физических узлах;

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

Графически диаграмма развертывания представлена на рис. 3.20.

диаграмма размещения

Рис. 3.20. диаграмма размещения

Для построения программной модели целесообразно определить спецификации классов. Построение спецификаций классов - это процесс документирования атрибутов классов, целью которого является подготовка к кодированию программной модели системы. Спецификация классов приведена в приложении "Б".

Процесс тестирования программной модели приведен в приложении "В".

Основной итог исследований, представленных в разделе. 3 - это предложение по созданию на АТЗК виртуальных предприятий системы ТЕА-АСУ в виде предпринимательских ЛИПС (см. §3.1.2), направленных на реализацию новой системы обеспечения надежности - системы FRACAS, как основы внедрения на АТЗК современных ИПВ-технологий.

 
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 

Предметы
Агропромышленность
Банковское дело
БЖД
Бухучет и аудит
География
Документоведение
Естествознание
Журналистика
Инвестирование
Информатика
История
Культурология
Литература
Логика
Логистика
Маркетинг
Математика, химия, физика
Медицина
Менеджмент
Недвижимость
Педагогика
Политология
Политэкономия
Право
Психология
Региональная экономика
Религиоведение
Риторика
Социология
Статистика
Страховое дело
Техника
Товароведение
Туризм
Философия
Финансы
Экология
Экономика
Этика и эстетика
Прочее