4.15. Проблема перекрытия сенсоров задней половины станции рамой и узлами с электроникой передней половины станции
STS нужно разместить в тесном магните, таким образом самая высокая восьмая станция ограничена по высоте [12]. Для устранения перекрытия сенсоров задней половины восьмой станции передней половиной необходимо выровнять по высоте, расположенный друг напротив друга в соседних станциях линейки, как показано на рисунке 4.45. Для устранения перекрытия нужно менять компоновку линеек, выбирая нужные строки в таблицах параметров.
На первые шесть станций не налагается жестких ограничений по высоте, таким образом для устранения перекрытий достаточно выровнять длины всех ферм станции, посредством изменения параметров “add_offset”, “offsetValue”, а также параметра “central_offset” для центральных линеек.
Рисунок 4.45 – Устранение перекрытия сенсоров задней половины восьмой станции узлами с электроникой и рамой
Для седьмой и восьмой станций выравнивание всех длин ферм не является решением проблемы, так как необходимо экономить место для вывода проводов.
4.16. Средства анализа и иллюстрации имеющихся технических и компоновочных решений STS 4.16.1. Проектирование базы данных для хранения и накопления информации о технических и компоновочных решениях STS 4.16.1.1. Основные понятия и определения
База данных – поименованная совокупность организованных определенным образом данных, отражающая состояние описываемых объектов и отношений между данными в рассматриваемой предметной области [7].
Система управления базами данных (СУБД) – специальные лингвистические и программные средства, используемые для управления данными: доступа к данным, их обновления и пополнения.
Инфологическая модель – модель базы данных, выражающая информацию о предметной области, ее объектах, их свойствах и их взаимосвязях в виде, независимом от используемой СУБД.
Инфологическая модель базы данных, представленная на восьмом графическом листе в приложении, была создана в программе Enterprise Architect. Инфологические модели данных используются на ранних стадиях проектирования для описания структур данных в процессе разработки приложения.
Фактографическая модель базы данных имеет структуру “объект – свойства – значения”. Сущность – множество однотипных объектов в фактографической модели. Атрибуты сущности – свойства объектов.
Одной из наиболее популярных фактографических моделей является модель “сущность - связь” (ER - модель). В данной модели представлено множество сущностей и отношений между ними.
В реляционных моделях баз данных отношения между сущностями представляют в виде таблиц. Отдельная строка таблицы (экземпляр отношения) называется кортежем и соответствует одному экземпляру сущности. Отдельный столбец таблицы соответствует одному из экземпляров сущности.
4.13.1.2. База данных для организации и хранения имеющихся технических и компоновочных решений STS
В дипломном проекте база данных используется для организации и хранения имеющихся технических и компоновочных решений STS, обеспечения доступа к отдельным данным посредством sql запросов.
Схема с базой данным называется “sts_analysis”. Схема включает в свой состав 25 таблиц.
Все используемые в базе данных сущности можно разделить на 4 группы:
Сущности, являющиеся основными конструктивными узлами STS:
sts;
unit;
half_station;
ladder;
sector;
el_box;
feb;
quarter_station;
frame;
cooling_plate.
Сущности, представляющие собой разновидности конструктивных элементов:
unit_variants;
ladder_variants;
sector_variants.
Для примера рассмотрим разновидности конструктивного элемента линейка. В модели STS в зависимости от требуемого пространственного расположения конкретной линейки используются либо обычные линейки, либо линейки с маленьким центральным вырезом под трубу, либо линейки с большим центральным вырезом под трубу;
Сущности, представляющие собой вопросы к конструктивным элементам:
sts_questions;
half_station_questions;
ladder_questions;
sector_questions;
el_box_questions;
feb_questions.
Экземплярами таких сущностей является набор вопросов к конструктивному элементу, которые подлежат теоретической и экспериментальной проверке;
Сущности, представляющие собой ответы на вопросы к конструктивным элементам:
sts_solutions;
half_station_solutions;
ladder_solutions;
sector_solutions;
el_box_solutions;
feb_solutions.
Рассмотрим наборы атрибутов, присущие каждому из четырех групп сущностей.
На рисунке 4.46 представлены наборы атрибутов для конструктивного элемента сектор, для вариантов данного конструктивного элемента STS, для вопросов и решений к нему.
Рисунок 4.46 – Наборы атрибутов, присущие сущностям разных групп
Набор атрибутов для сущностей первой группы:
Id_sector – первичный ключ конструктивного элемента сектор;
Description – описание конструктивного элемента сектор;
Id_ladder – внешний ключ, использующийся для связи таблицы сектора и линейки. Связи такого рода говорят о механической связи между конструктивными элементами;
Link_to_figure – ссылка на изображение конструктивного элемента.
Набор атрибутов для сущностей второй группы:
Id_sect_var – первичный ключ сущности;
Name_sect_var – имя варианта конструктивного элемента;
Description – описание особенностей, присущих данному варианту конструктивного элемента;
Id_sector – внешний ключ, связывающий таблицу конструктивного элемента с таблицей его вариантов;
Link_to_figure – ссылка на изображение варианта конструктивного элемента.
Набор атрибутов для сущностей третьей группы:
Id_sector_question – первичный ключ сущности;
Description – вопрос к конструктивному элементу;
Id_sector – внешний ключ, связывающий таблицу конструктивного элемента с таблицей вопросов к нему;
Check_method – метод проверки вопроса.
Набор атрибутов для сущностей четвертой группы:
Id_sect_solution – первичный ключ сущности;
Name_sect_solution – название решения;
Description – описание особенностей решения;
Check_result – статус работы над данным решением (“not answered”, “in work”, “closed”);
Check_doc – ссылка на документ, поясняющий данное решение;
To_use – рекомендация к использованию данного решения;
Advantages – положительные стороны решения;
Disadvantages – отрицательные стороны решения;
Link_to_figure – ссылка на изображение, иллюстрирующее решение вопроса;
Id_sector_question – внешний ключ, связывающий таблицу решений с таблицей вопросов.
Возможные варианты атрибута “check_method”:
“MC simulation” – для решения поставленного вопроса необходимо использовать метод Монте-Карло;
Рисунок 4.47 – Варианты решения вопроса: а) Чувствительные зоны секторов не перекрываются; б) Чувствительные зоны секторов перекрываются
Пример вопроса данного типа - чувствительные зоны сенсоров в составе сектора должны перекрываться или в этом нет необходимости. Варианты решения данного вопроса показаны на рисунке 4.47.
“Technology” – в качестве решения вопроса принимается наиболее технологичный вариант;
Пример вопроса данного типа – кабели идут от сектора к FEB с разных сторон сектора или с одной стороны. Варианты решения данного вопроса показаны на рисунке 4.48.
Рисунок 4.48 – Варианты решения вопроса: а) Кабели идут к FEB с разных сторон сектора; б) Кабели идут с одной стороны сектора
“Prototype testing” – для решения вопроса необходимо провести тестирование прототипов;
Пример вопроса данного типа – в пределах одной станции линейки располагаются друг напротив друга или в шахматном порядке. Варианты решения данного вопроса показаны на рисунке 4.32.
“Mounting scenario” – решением вопроса является установленная последовательность некоторых действий.
Пример вопроса данного типа – последовательность монтажа / демонтажа модуля из линейки. Последовательность демонтажа модулей из линейки показана на седьмом листе в приложении.
Связи между таблицами конструктивного элемента, его возможных вариантов, вопросов к конструктивному элементу и решений показаны в виде части инфологической схемы, представленной на рисунке 4.49.
Рисунок 4.49 – Связи между сущностями разных групп
4.13.1.3. Работа с базой данных, извлечение информации
Извлечение информации, содержащейся в базе данных, с помощью СУБД осуществляется посредством sql запросов.
На данный момент важно быстро получить список всех имеющихся вопросов ко всем компонентам STS, получить список всех вопросов, решаемых определенным методов, список уже решенный вопросов с указанием способа его решения и с ссылками на документы, обосновывающими данное решение.
Часть таблицы, в которой представлен список всех вопросов к модели STS, представлена на рисунке 4.50.
Таблица, в которой представлен список всех вопросов, которые необходимо проверить на технологичность, представлена на рисунке 4.51.
Рисунок 4.50 – Список всех вопросов к модели STS
Рисунок 4.51 – Список всех вопросов, которые необходимо проверить на технологичность
4.16.2. Разработка ассоциативной карты для представления технических и компоновочных решений STS в Xmind
Программа Xmind предназначена для создания ассоциативных карт, имеющих древовидную структуру, на которых изображаются слова, идеи, задачи или другие понятия, связанные ветвями, отходящими от центральной идеи или понятия.
В нашем случае центральным узлом древовидной схемы является “Компоновка узлов STS”. Основные вопросы и проблемы, подлежащие решению, изображаются на узлах схемы, непосредственно связанных с центральным. От узлов с описанием проблемы отходят ветви, в которых описываются разные варианты ее решения с указанием достоинств и недостатков каждого варианта. К узлам схемы можно прикреплять картинки, что делает сами проблемы или способы их решения более наглядными, также к узлам можно прикреплять комментарии, ссылки на документы, на web страницы. Также Xmind предоставляет возможность для наложения связей между произвольными узлами схемы, что показано на рисунке 4.52.
Рисунок 4.52 – Зависимость между произвольными узлами в Xmind
Xmind хорошо справляется с задачей визуализации имеющихся технических и компоновочных решений STS, а также связей между ними, но в Xmind нет встроенных средств для какого-либо анализа внесенной информации. Мы можем внести информацию о всех имеющихся вопросах к компоновке STS, но мы не сможем, выполнив какую-либо команду, получить сведения о всех обозначенных в схеме вопросах.
Для анализа имеющейся информации используются sql-запросы к базе данных, результаты выполнения которых посредством использования PHP представляются в виде html-документа.
В данном проекте в качестве сервера для PHP был использован IIS. Для обеспечения возможности отправки sql-запросов с помощью PHP и обработки результатов необходимо изменить конфигурационный файл php.ini, чтобы при написании PHP кода можно было использовать библиотеку функций для работы с базой данных PostgreSQL.
В разработанную ассоциативную карту была добавлена ссылка на созданную динамическую html-страницу, на которой пользователь должен выбрать тип вопросов, информация о которых будет извлечена из базы данных посредством использования PHP кода. Результатом такого запроса, будет html-страница, в которой будут представлены все возможные решения всех вопросов выбранного типа. Также представляется возможность извлечь из базы данных все возможные решения всех типов.
Ассоциативная карта, составленная в Xmind для иллюстрации имеющихся технических решений и зависимостей между ними, представлена на девятом графическом листе в приложении. Ссылка на html-страницу с выбором типа вопросов, а также результаты обработки запроса в виде html-документа представлены на девятом графическом листе в приложении.
|
