# NOC Inventory Liftup

На настоящий момент inventory NOC базируется на 3 сущностях:

* ObjectModel - задают параметры объекта и возможные соединения
* Object - являются экземпляром модели и представляют объект реального мира
* ObjectConnection - Задает связь между connnections различных объетов

Connections в модели задают одно из трех направлений:

* `o` (outer), соединение, через которое объект может быть вставлен в другой объект. Обычно один на модель. Со стороны другого объекта ему должно соответсвовать направление `i`
* `i` (inner), соединение, через которое в объект может быть вставлен другой объект. Со стороны вставляемого объекта ему должно соответсвовать направление `o`
* `s` (side), одноранговая связь между объетами, с другой стороны также соответсвует направлению `s`

Для задания любой связи между объектами, вне зависимости от направления, создается отдельная запись ObjectConnection вида:

* connection - список
* object - ссылка на объект
* name - имя connection в модели
* data - на насттоящий момент не используется.

Кроме того, существуют объекты-контейнеры, которые могут содержать внутри себя другие объекты не используя connections. Для этого в структуре Object предусмотрено поле:

* `parent` - ссылка на родительский объект

Формально, с точки зрения пользователя, база inventory представляет собой дерево, отдельные узлы которого дополнительно связаны между собой горизонтальными связями и, возможно, промежуточными объектами за пределами иерархии.

При этом связи между объектами можно разделить на 2 категории:

* Вертикальные: `i` -- `o` и через `parent`
* Горизонтальные: через направление `s`

При этом текущая схема имеет ряд недостатков:

* Кабели являются объектами, но они не обязаны содержаться внутри одного контейнера и выпадают из иерархии
* Для кабелей необходимо создавать модели, что из-за большого количества комбинация может быть затруднительно
* С кабельной канализацией более-менее понятна ситуация с колодцами и кабельными вводами, кабельные каналы до конца не проработаны.
* Дуализм при формировании вертикальных связей - на верхних уровнях связь осуществляется через parent, на нижних - через object connection. таким образом нельзя использовать иерархические запросы.
* Вертикальные связи `i` -- `o` требуют отдельной записи Object Connection, хотя им реально не соответсвует никакой физической сущности
* Не проработан вопрос с картами двойного размера (занимают два слота). Формально они могут моделироваться через ObjectConnection, но на настоящий момент реально не используются.
* "Геометрический дуализм" - объект может быть как точечным, так и географически протяженным.

## Предлагаемое решение

* Унифицировать вертикальные связи
* Использовать Object Connection только для горизонтальных связей. Таким образом, Object Connection становится кабелем, радиоканалом, связью между колодцами
* Признать Object материальной точкой
* Признать ObjectConnection географически протяженным объектом
* Объект всегда является частью иерархии (запрет на висячие объекты)

### Доработка модели Object

Модель Object дополнияется полями:

* `parent` - ссылка на родителя (поле уже существует под именем `container`)
* `parent_connection` - опциональное имя connection у родителя, куда вставляется объект. Для контейнеров - пустое
* `additional_connections` - список дополнительных connections у родителя, которые занимает вставляемый объект.

Также текущий индекс по parent заменяется на индекс по (parent, parent_connection)

Таким образом полностью устраняется необходимость создавать запись ObjectConnection для вертикальных связей и весь проход по дереву выполняется единообразно.

**Пример 1: Контейнеры**

Моделируются идентично текущей модели. Если объект Child вложен в объект Container то:

* Объект Container остается неизменным
* У Объекта Child:
* поле parent устанавливается в id Container

**Пример 2: Линейные карты**

Пусть карта `LC` вставлена в слот `slot3` объекта `Box`

* Объект `Box` остается неизменным
* У объекта `LC`:
* поле `parent` устанавливается в id Box
* поле `parent_connection` устанавливается в `slot3`

**Пример 3: Двойная карта**

Пусть карта `LC` вставлена в слот `slot3` объекта `Box`, но она также занимает слот `slot2`

* Объект `Box` остается неизменным
* У объекта `LC`:
* поле `parent` устанавливается в id Box
* поле `parent_connection` устанавливается в `slot3`
* поле `additional_connection` устанавливается в [`slot2`]

## Модель ConnectionModel

Настройки параметров соединений, представляет из себя усеченный ObjectModel оптимизированный для работы с кабелями:

* name - уникальное имя
* uuid - UUID для коллекций
* description - опциональное описание
* data - данные, аналогично параметрам ObjectModel
* plugins - список Inventory Plugins
* n_pairs - количество "волокон"

@todo: Группировка волокон по модулям
@todo: Допустимые протоколы
@todo: Допустимые разъемы
@todo: Плетка-семихвоска

## Доработка модели ObjectConnection

Добавляются поля:

* model - Ссылка на ObjectModel
* data - аналогично Object Data
* connections
* object - присоединенный объект
* name - connection присоединенного объекта
* connection_type - вычислимый connection type, см. далее
* pair - номер пары (см. далее)
* path - список точек прохождения
* layer - ссылка на слой GIS
* line - PolyLine для отображения на карте

@todo: path должен содержать как промежуточные объекты так и вкладываться в object connection (i.e. кабельные каналы)

Кабели, особенно оптические, часто бывают абсолютно разнородными по составу разъемов. Чтобы не создавать модели на все возможные комбинации предлагается ad-hoc механизм формирования connection type на каждый стык по следующему алгоритму:

* Если у объекта connection type имеет два пола - male и female, записываем противоположный тому, который имеет соответсвующий connection объекта
* Если connection type содержит c_group, берем его из c_group (как в случае с C13/C14)

Кабель по своей природе часто реализует внутри себя топологию типа bunch, поэтому различные пары соединений разделяются различными значениями pair.

@todo: Рассмотреть случай разветвляющихся кабелей

## Дискриминаторы

### Fiber

Указывает волокно в кабеле. Имеет вид:

* `fiber:<N>`, где `<N>` - номер волокна или пары (начиная с 1)
* `fiber:<M>-<N>`, где `<M>` номер модуля (начиная с 1), `<N>` - номер волокна или пары в модуле (начиная с 1)

Используется на уровне муфты или патч-панели в crossing

### Conduit

Указывает трубу, по которой проходит кабель. Используется при прохождении кабеля через кабельный канал, связывающий два колодца.

* `conduit:<N>`, где `<N>` - номер трубы

См. Model Interface `conduit`

## Model Interface

### pair_color

Задает цветовую схему пар.

* module_color - список цветов модулей
* pairs - список имен пар/волокон (i.e. 1, 2, 3 или 1-1, 1-2, 1-3, ...)
* pair_color - список цветов волокон в модуле

@todo: Справочник цветов?

@todo: Рассмотреть варианты как с одинаковыми, так и с различающимися по конфигурации модулями

### conduit

Задает положение труб в кабельном канале.

* conduits - список параметров труб

Параметры труб задаются для каждой трубы в кабельном канале и имеют вид `<d>-<x>-<y>`, где:

* `<d>` - диаметр трубы в мм
* `<x>` - горизонтальная координата в мм относительно локальной системы координат плана
* `<y>` - вертикальная координата в мм относительно локальной системы координат плана

Каждая труба описывается отдельным независимым набором параметров. Локальная система координат распологается в левом верхнем углу схемы, вертикальная ось направлена вниз.

Рассмотрим пример кабельного канала с 6 трубами диаметром 100мм.


"conduits": ["100-50-50", "100-150-50", "100-250-50", "100-50-150", "100-150-150", "100-250-150"]

## Примеры

### Кабельная канализация

Состоит из 3 основных сущностей:

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

**Колодец**

Модель `Ducts | Manhole`. Содержит connection `conduits` с connection type `Conduit`

**Кабельный ввод**

Модель `Ducts | Cable Entry`. Содержит connection `conduits` с connection type `Conduit`

**Кабельный канал**

Object Connection с моделью `Ducts | Conduit`

## Этапы

1. Переменовать `container` в `parent`
2. Преобразовать ObjectConnection для вертикальных связей в ссылку на parent + parent_connection
3. Заменить объекты-кабели на object connection