Разбор сообщения по первой части КП

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Разбор сообщения по первой части КП

Сообщение tor_root » 24 окт 2011, 12:50

По состоянию на 24.10.2011 на портале опубликовано два сообщения по первой части КП
Локальная радиосеть Зенкиной Дарьи и
Система сбора данных с подвижных станций Андреева Сергея.

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

Итак, формулировка задания:
1.1. Анализ поставленной задачи и исходных данных, выявление особенностей работы системы. Цель – проработка идеи создания сети как целостной системы. Краткое описание концепции функционирования системы связи на основе проведенного анализа. Определение списка основных и дополнительных услуг системы, предоставляемых пользователям. Обоснование необходимости организации различных профилей функционирования.

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

Телеметрические данные (телеметрия) – это информация, которая будет позволять в совокупности техническим устройствам проводить удалённое измерение и сбор материалов для предоставления оператору или пользователю, т.е. по своей сути эти данные организуют дистанционное управление. Для сбора информации используются либо датчики телеметрии (специально встроенные модули связи), либо устройства связи с объектом, к которым подключаются обычные датчики.
Не понятно назначение приведенных предложений. Без четкого формулирования задач сети рассуждать о каких-то датчиках и системах бессмысленно.

В КП будет реализован первый вариант. В качестве среды передачи используется беспроводная сеть GSM/GPRS технология пакетной передачи данных посредством сотовой связи с выделением отдельного канала), максимально возможная скорость передачи данных составляет 171,2 Кбит/с.
Для решения основной задачи проекта использовать готовые коммерческие решения недопустимо. В качестве доп. подсистем, выполняющих вспомогательные задачи, возможно использование существующих спецификаций/технологий.

За идею разработки системы будет принят метод спутниковой системы навигации ГЛОНАСС, например маршрут трамвая города Тула, т.е. организован мониторинг (процесс наблюдения и регистрации данных) транспортных средств, где будет выполнено одно из условий КП – одновременное обслуживание нескольких подвижных объектов.
За идею разработки системы не может быть принят "метод спутниковой системы навигации ГЛОНАСС". Вообще непонятно, что подразумевается под "методом спутниковой системы навигации, например маршрут трамвая города Тула"? Трамвай г.Тула является секретным модулем системы ГЛОНАСС? Странно это слышать от человека, которому был прочитан курс по СНС.

Искусственный спутник Земли становится радионавигационной опорной станцией, координаты которой изменяются во времени вследствие движения спутника по орбите ( для ГЛОНАСС - 19100 км).
Несколько раз прочитал фразу, но так и не понял, какое отношение имеет движение НКА по орбите к теме Вашего проекта?

В качестве дополнительных услуг, предоставляемых пользователям, возможно, использовать контроль открытия/закрытия дверей транспорта, исключая несанкционированные остановки, а также контроль направления движения и скорости транспорта, детализация маршрута на карте.
Без формулирования основных услуг сети не имеет смысла распространяться о дополнительных.

Итог: задачи п.1.1 не выполнены. Выбрана тупиковое с т.з. учебной работы направление движения. В дальнейшем, во избежание проблемы, необходимо прорабатывать тематику поддержки спортивных мероприятий с самостоятельной разработки подсистемы передачи данных.

1.2. Проработка обобщенной функциональной схемы системы: выявление основных ее компонент и определение возможных функциональных связей. Анализ подходящих топологий организации сети и обоснованный выбор достойного решения.
Принцип работы системы основан на установке бортового оборудования, включающего в себя: спутниковый ГЛОНАСС-приёмник, радиостанцию для передачи информации по УКВ-каналам и GPRS-модем для передачи информации по GPRS.
Принцип работы системы не может быть основан на установке бортового оборудования!

При помощи этих устройств осуществляется определение курса, скорости, текущих координат, происходит сбор информации с датчиков транспортного средства (транспортное средство получает данные от спутников и передаёт их на серверный центр мониторинга посредством GSM). УКВ связь является ещё одной особенностью системы и актуальна для мониторинга в местах, где отсутствует полноценное GSM-покрытие.
Назначение всевозможных функциональных модулей, о которых идет речь в п.1.2, должно следовать из анализа поставленной задачи (п.1.1) и никак иначе.

Стандарт GSM предусматривает работу передатчиков в двух диапазонах частот: 890-915 МГц для передатчиков подвижных станций- MS), 935-960 МГц (для передатчиков базовых станций BTS). Значение МS можно принять как минимальный диапазон используемых частот ТЗ.
Неясно и технически неграмотно. Непонятно, какое это имеет отношение к проработке обобщенной функциональной схемы системы?

Тогда радиомаяк, находящийся на теле транспорта (радиус зоны 90м) будет являться GPRS-модемом, а базовые станции GSM, как терминалы сбора данных будут располагаться на расстоянии 90 м друг относится друга, чтобы постоянно контролировать перемещение транспорта. GPRS-модем (трекер) – это центральный, приёмо-передающий прибор системы слежения за транспортом, который определяет текущее положение объекта в пространстве (координаты), а так же производит сбор информации с подключённых к нему датчиков.
А это вообще феерично: расположение BTS на расстоянии 90м избыточно даже для шанхайского метро в часы пик, а использование BTS GSM для решения поставленной задачи вызывает недоумение. И вообще, из приведенных абзацев следует, что "GPRS-модем (трекер) – это центральный, приёмо-передающий прибор системы,... находящийся на теле транспорта". Без комментариев...

Рисунок 2. Пример использования GPRS –модема
Рисунок 3. Функциональная схема навигационного приёмника ГЛОНАСС

Несмотря на отсутствие рисунков в сообщении уже понятно, что такие рисунки здесь не нужны.

Как правило, типовой приёмник сигналов ГЛОНАСС состоит из четырёх функциональных частей: антенной системы; радиочастотной части; цифрового блока корреляционной обработки; навигационного процесса. В качестве антенны обычно используется микрополосковая антенна, обладающая малой массой и габаритными размерами.
Вместо проработки обобщенной функциональной схемы системы и определения функциональных связей между блоками схемы была представлена примитивная трактовка приемника СНС, больше подходящяя к изложению "GPS для суперчайников". По всей видимости, г. Андреев так увлекся работой, что не заметил подмены задания...
Итог: задачи п.1.2 не выполнены. Без основательной проработки п.1.1. не имеет смысла приступать к п.1.2.

1.3. Определение и обоснование структуры информационной подсистемы сети. Выявление важнейших регистров подсистемы, пояснение необходимых информационных связей.
Самым существенным различием систем мониторинга является функциональность серверного и клиентского программного обеспечения, возможность разносторонне обрабатывать данные.Разновидностью последнего варианта является программное обеспечение, использующее трёхуровневую архитектуру (клиент, сервер приложений, сервер базы данных), когда компоненты и функции центра обработки данных распределены между несколькими серверами: база данных, картографической подсистемы, телекоммуникационным сервером и сервером приложения, обеспечивающего работу web-интерфейса пользователя. ПО для спутникового мониторинга обычно имеет ряд интерфейсов. Вход пользователей в систему чаще всего защищён паролем.
Информационная подсистема сети - совокупность информационных связей, объединяющих функциональные модули системы и реализующих все услуги сети. Физически - это БД, но вот то, что реализуется на ее основе - это предмет работы в этом пункте задания. Термин БД здесь можно не применять. Структура информационной подсистемы сети должна логично следовать из основного назначения системы (п.1.1) и из специфики функциональных связей (п.1.2).

На структурном уровне система GPRS делится на две части: подсистема базовых станций и ядро сети GPRS. В подсистему БС входят все контроллеры и базовые станции GSM, которые поддерживают пакетную передачу данных на программном и аппаратурном уровне. Ядро сети GPRS включает в себя сетевые элементы, предназначенные для обработки пакетов данных и обеспечения связью с сетью Интернет. Основными элементами являются: пакетный коммутатор – SGCN (Serving GPRS Support Node). Данный сетевой элемент берёт на себя функции обработки пакетной информации и преобразования кадров GSM в форматы, используемые протоколами TCp/Ip глобальной компьютерной сети Internet. Шлюз GGSN (Gataway GPRS Support Node) – обеспечивает связь системы GPRS с пакетными сетями передачи данных Internet, содержит необходимую информацию о сетях, куда абоненты GPRS могут получать доступ, а также параметры соединения.
Рисунок 4. Структурный уровень системы GPRS

Не понятно - к чему это примитивное описание подсистемы GPRS?

Для того чтобы использовать возможность передачи данных системой GPRS, требуется специальный терминал, поддерживающие работу в режиме GPRS. В КП скорее всего будет использоваться класс С (карты PCMCIA, CF и ГЫИ адаптеры) – терминал обеспечивает передачу только в пакетном режиме.
К счастью, в КП не будет использоваться ни класс С, ни какой-либо другой класс терминалов GPRS.
По крайней мере, для решения основной задачи проекта...

Итог: задачи п.1.3 не выполнены. Отсутствует критический и вдумчивый анализ имеющихся данных, осуществлена подмена поставленных задач некими тривиальными сведениями.

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Рецензия на сообщение Горюшкина Руслана

Сообщение tor_root » 26 окт 2011, 23:59

На этот раз мое подробное внимание будет уделено первому сообщению Горюшкина Руслана по теме работы "Радиосеть передачи данных". Разбор его работы обязателен для ознакомления всех собратьев по несчастью.
Эта работа, как и практически все представленные ранее, свидетельствуют о полном непонимании тех задач, которые сформулированы в задании. Для того чтобы дать ответы на незаданные вопросы на проводимых консультациях, подробно разберу п.1.1.

Формулировка задания:
1.1. Анализ поставленной задачи и исходных данных, выявление особенностей работы системы. Цель – проработка идеи создания сети как целостной системы. Краткое описание концепции функционирования системы связи на основе проведенного анализа. Определение списка основных и дополнительных услуг системы, предоставляемых пользователям. Обоснование необходимости организации различных профилей функционирования.

Как попытался решить задачи Руслан:
Для уменьшения дипазона частот целесообразно применить временое разделение каналов, при этом неколько мобильных станций(МС) имеют возможность работать в одной полосе частот совместно, используя разные временые слоты для передачи данных.
Зона обслуживания сети имеет радиус 3 км и располагается в пригороде. Относительно небольшой радиус зоны обслуживания и тип местности с неплотной застройкой позволят использовать одну базовую станцию (БС), находящуюся в зоне прямой радиовидимости. Однако, для минимизации излучения МС будет использоваться сеть из БС.
Возможна организация дополнительных услуг: обмен данными внутри локальной сети, обмен текстовыми сообщениями.


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

С чего надо было начать? Думаю, что с абстракции.

В задании представлены требования и некоторые параметры разрабатываемой системы. Если эта часть задания понятна, то первым этапом анализа поставленной задачи должно быть изложение идеи построения сети (системы); это изложение не должно затрагивать предполагаемые особенности физического или канального уровня системы.

В первом приближении система для нас на начальном этапе представляется в виде "черного ящика", который что-то берет у абонента на своем входе и это что-то без изменений передает на свой выход. Чтобы стала предельно понятной моя мысль, представим себе, что роль черного ящика выполняет бухта кабеля, соединяющая абонента с провайдером услуг передачи данных. И вот мы, разработчики такой системы, должны четко прописать правила применения такого черного ящика: в зависимости от подписанной у провайдера услуги, вы указываете наиболее подходящую марку кабеля, как (или где) его приобрести, к чему и как он подключается у абонента и с другой стороны - у провайдера. Публикуем прайс, сажаем девочку за кассовый аппарат, нанимаем бывшего студента-неудачника в качестве грузчика кабеля и наслаждаемся своим бизнесом...
Таким обазом, если предоставляемые системой услуги связаны с передачей данных, то понятно, что входом и выходом разрабатываемой системы будут потоки данных под управлением одного и того же протокола. Какие могут быть потоки, где они рождаются и как передаются по физической среде - не такая уж и сложная аналитическая задача для студента 5 курса радиоуниверситета.

И вот когда становится понятным что будет передавать система, от кого, с помощью чего и куда (и, возможно, как), то наступает самое время автору проекта сделать следующий шаг: ответить, на первый взгляд, на очевидные и простые вопросы:
1. Какие услуги будет предоставлять система с точки зрения транспортных возможностей "черного ящика" (в смысле поддерживаемых протоколов). Если предполагаются сервисные услуги, не связянные со сквозной передачей данных, то помимо декларативного их перечисления требуется пояснить идею их реализации.

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

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

2. Из каких обобщенных функциональных узлов будет состоять система? Чем придется воспользоваться абонентам, что будет находиться у провайдера. Как предполагается управление настройками абонентского терминала, какое предполагается управление терминалом со стороны сети и т.п. Здесь проводится анализ потребительских и очевидных на этом этапе технических параметров основных узлов системы.
Подробное изложение функциональных связей и доп. подсистем должно быть представлено в п.1.2 и естественным образом следовать из п.1.1.

3. Как, узнав о существовании сети, потенциальные абоненты смогут подписаться на услуги системы? Какая организационная процедура по мнению автора проекта здесь может иметь место? Какие сведения потребуются системе об абоненте и абоненту о системе? Оборудование покупается, приобретается, предоставляется на время и т.п.?

4. Отвечаем на вопросы, которые не дают покоя творческим лицам, взламывающим между делом коммерческие системы: какие закладываем процедуры авторизации, идентификации, возможности по шифрованию трафика (постоянные или опциональные), как реализация всего этого видится на уровне обобщенной проработки сети? Несомненно уместным здесь было бы основательное рассуждение автора проекта по вопросу обеспечения идентификации как собственно терминалов, так и абонентов, не упуская из вида будущую иерархическую модель системы.

Подробное изложение ответов на очень простые вопросы вышеперечисленных пунктов является "Анализ поставленной задачи". Вот только после этого можно будет приступать к "Краткому описанию концепции функционирования системы связи на основе проведенного анализа."
Не допускается оставлять без ответа последний вопрос пункта задания "Обоснование необходимости организации различных профилей функционирования". Аргумент в виде предоставленных доказательств недостаточности собственного IQ для решения этой задачи не является доводом ее игнорировать.

Закончив работу над п.1.1 вполне уместно приступать к п.1.2, но это уже совсем другая повесть...

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Сергею Андрееву

Сообщение tor_root » 27 окт 2011, 00:37

Сергей, начну с того, что процитирую слова удивительного персонажа "Платон мне друг, но истина дороже". Нам еще рано останавливаться на достигнутом...
Что касается п.1.1 - на мой взгляд уже существенно лучше предыдущего варианта, но этого явно недостаточно.
Концепция функционирования системы изложена как-то сумбурно, анализ поставленной задачи незавершен: радиомаяки на спортсменах собирают и передают телеметрию - какую, как на нее должна реагировать система? Как видится Вам способ фиксации прохождения спортсменов через контрольную точку, каким образом реализуется множественный доступ, какие нужно закладывать решения по энергосбережению и т.п.
Абзац с термином радиопеленгация - это нечто...

Остальные разделы - как в тумане, что-то виднеется, но вот что? На каком основании выбирается мощность излучения, диапазон частот?? Это же станет известным лишь при построении физ. уровня, не раньше.

Вывод: требуется четче и яснее излагать свои мысли, без погружения в собственную виртуальную реальность.
Думаю, что будет полезным для Вас ознакомление с рецензией выше: viewtopic.php?f=33&t=166&p=564#p564.

Желаю удачи и полного раскрытия своего потенциала.

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Кристине: Система сбора данных с подвижных станций

Сообщение tor_root » 27 окт 2011, 19:43

Отзыв на первое сообщение Маркиной Кристины по теме "Система сбора данных с подвижных станций".
Особенностью данного сообщения является достаточно обстоятельное описание идеи функционирования системы сбора данных, совмещенный с анализом поставленной задачи. На мой взгляд, в статье Кристины имеется понимание основных задач системы, предлагается вполне реализуемая схема построения сети и в общих чертах проработан сценарии взаимодействия объектов сети.
Работа в целом оставляет положительное впечатление, она станет еще лучше, если будут учтены следующие замечания.
1. Некоторая терминологическая перегруженность: вначале сообщения используется "терминал", потом "радиомаяк", следом "подвижные датчики" ; представляется неудачным название "узел-концентратор" - может точка сбора данных, она же образует зону радиопокрытия, в пределах которой осуществляется съем данных. "Контроллер узлов" - это что-то узко специализированное, в контексте обобщенного анализа системы для этого модуля больше подходит введенное в начале сообщения понятие центра сбора информации . Если требуется особо выделить подсистему управления точками сбора (концентраторами), то эти функции целесообразно выделить в отдельный модуль.
2. Отсутствует анализ особенностей системы. Помимо основного назначения терминалы осуществляют сбор и накопление тлеметрической информации. Часть такой информации может являться оперативно важной, необходимой для принятия решения и которую требуется передавать в процессе выступления, а другая часть может представлять интерес для неспешного анализа после выступления - в этом отношении нет необходимости перегружать канал связи избыточными сообщениями. Это обстоятельство накладывает определенные требования на функционал терминала.
3. Не затронут вопрос идентификации терминалов, концентраторов; неясным остается тип интерфейса связи "Контроллер узлов" - "концентратор". Выпала из анализа поставленной задачи подсистема точного времени - измерения и факт фиксации события должны быть привязаны к каким-либо временным меткам? Должны ли быть часы в терминалах? Надо думать...
4. Не упомянуты возможные профили функционирования радиосистемы. Это вопрос имеет отношение к гибкой настройке компонент системы для решения разных задач. Это, в свою очередь, означает, что должен быть проработан вопрос о способах настройки сетевых устройств (терминалов и концентраторов), том числе о привязке терминала к конкретной лошади и т.п . Какие могут закладываться правила конфигурирования терминалов, концентраторов?
5. По всей видимости у терминала несколько функциональных состояний, важнейшие из них могут быть отражены на этом этапе: помимо того, что терминал может быть включен, он должен дополнительно активизироваться (видимо по команде извне) в момент старта или незадолго до него. Целесообразно иметь возможность удаленного включения/выключения портов съема данных с датчиков - не всегда же нужно задействовать весь потенциал терминалов?
6. Обобщенная функциональная схема все-же должна отражать те ососбенности, о которых шла речь выше. К примеру: факт наличия у терминала портов чтения телеметрических данных, оперативной памяти для хранения записываемых данных, условно диспетчера режимов работы терминала, собственно радиомодуля и т.д.
7. Выбор для физического уровня метода множественного доступа CDMA является не лучшим с т.з. учебной работы. Надо использовать TDMA и поразмышлять о том, как будет в системе обеспечивать множественный доступ.
8. Не отражен п.1.3 задания.
В остальном все хорошо.
Надеюсь ничего не упустил.
Удачи!

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Краткие замечания к сообщению Кирилла Лизунова

Сообщение tor_root » 16 ноя 2011, 22:21

Обсуждаемая работа
1. Необходимо при оформлении сообщений придерживаться тех правил, которые отражены по ссылке.
2. Постановка задачи: 1.1. Анализ поставленной задачи и исходных данных, выявление особенностей работы системы. Цель – проработка идеи создания сети как целостной системы. Краткое описание концепции функционирования системы связи на основе проведенного анализа. Определение списка основных и дополнительных услуг системы, предоставляемых пользователям. Обоснование необходимости организации различных профилей функционирования.
В качестве примера использования разрабатываемой системы можно представить несколько многоквартирных домов, находящихся в радиусе 500м. В каждой квартире такого дома находятся электро- и газовые счетчики. Для каждого подъезда на крыше будет установлен маршрутизатор, к которому будут подключен каждый счетчик. В каждом маршрутизаторе будет находиться некоторый элемент ППЗУ, в котором будут храниться данные с каждого датчика. Так как показания счетчиком представляют собой небольшой объем данных, то не требуется большой объем запоминающего устройства. Также каждый маршрутизатор будет укомплектован радиомодулем, который будет передавать накопленные данные. Таким образом, внутридомовая топология сети будет иметь тип «звезда».
...
Работа данной системы будет происходить следующим образом. В конце каждого месяца (например, 25 число каждого месяца) каждый маршрутизатор будет опрашивать счетчики и записывать полученные данные в своей памяти. Всё остальное время он будет находиться в состоянии сна. Для сбора данных с маршрутизаторов будет использоваться подвижная станция. В конце месяца она будет проезжать рядом с домами, данные с которых требуется снять. Во время движения подвижная станция будет передавать по широковещательному каналу запросы. Получая эти запросы, маршрутизаторы просыпаются и начинают конкурентную борьбу. Как только один из маршрутизаторов выигрывает, то сразу начинает передавать накопленные данные. После окончания передачи на данный маршрутизатор будет отправлен флаг, который подтверждает факт приема данных. Так же в БД подвижной станции буден отмечен уже обслуживаемый маршрутизатор, и он уже не будет участвовать в борьбе. Так как объем передаваемых данных не велик, то для опроса всех маршрутизаторов не потребуется много времени. Для отслеживания в режиме online какие станции уже были обслужены, на борту подвижной станции будет находиться ПК, на котором будет установлено специальное ПО, которое будет взаимодействовать с БД. После сбора всех данных подвижная станция будет отправлена в центральный узел, где все полученные данные будут обработаны, и результаты занесены в центральную БД. В центральной БД все полученные данные будут соотнесены с конкретным потребителем, для чего будет использован уникальный идентификатор, который будет передаваться с результатами каждого счетчика.


Хорошо иллюстрация основной задачи системы. Но имеются следующие нестыковки:
- почему используется термин "маршрутизатор"? Да, вполне красивое слово, но вот проблема в том,что маршрутизатор предназначен совершенно для иных целей. Это назначение мы когда-то разбирали, здесь разночтений быть не должно. Как свидетельство взаимопонимания предлагаю Вам в ответе на это сообщение привести краткое и содержательное пояснение основной задачи маршрутизаторов.
- "В каждом маршрутизаторе будет находиться некоторый элемент ППЗУ" - такие подробности в данном разделе явно избыточны, тем более - ППЗУ??? Это постоянная память, в которой может храниться прошивка микроконтроллера (код программы) или т.п., но никак не оперативные данные, снимаемые с датчиков.
- представив многоквартирный дом становится ясным, что затея с проводами от датчиков до "маршрутизатора" не может быть удовлетворительным решением. Надо предложить более изящное решение - выбор и обоснование за Вами. Может применить трехзвеньевую структуру: датчики-радиомодуль-концентратор данных на лестничной площадке (или один концентратор на 2 пролета) - терминал сбора данных (подъезд) - подвижная точка сбора?
- без ответа остались некоторые вопросы из постановки задачи - помимо этого ответы должны быть агрументированными.
- рис.1 является неинформативным и как-то не вяжется с содержимым части сообщения. В любом случае, на каждый рисунок должна быть ссылка из текста.
3. Постановка задачи:
1.2. Проработка обобщенной функциональной схемы системы: выявление основных ее компонент и определение возможных функциональных связей. Анализ подходящих топологий организации сети и обоснованный выбор достойного решения.
Для съема данных раз в месяц в непосредственной близости от домов будет проезжать подвижная станция. На борту данной станции будет находиться:
1) Радиомодуль, который предназначен для передачи запросов и приема информации.
2) База данных (БД), которая будет содержать в себе списки маршрутизаторов, которые могут быть доступны.
3) Элемент памяти, в который будут записываться данные с каждого маршрутизатора.
4) ПК на котором будет установлено специализированное ПО, для отслеживания обслуженных маршрутизаторов.
Обобщенная схема сети будет выглядеть следующим образом:


Задача выполнена не полностью: требуется проработка обобщенной функциональной схемы именно всей системы. Была сделана не совсем удачная попытка отразить функциональную структуру подвижной точки сбора, но никак не отражены остальные элементы сети. Здесь же или в п.1.1 необходимо привести схему Вашей сети, отражающую ее особенности построения (топология+особенности).
Что касается представленного перечисления:
- невнятно отражена задача радиомодуля - если по идее он выполняет задачи точки доступа, то и решаемые им задачи должны быть соответствующие;
- п.2 и 3 - демонстрация непонимания смысла компонент. Что за элемент памяти? Есть инфрмационная среда - некоторое информационное хранилище, структура которого создается для выполнения необходимых Вам задач. То, что надо хранить, использовать в оперативной работе - все это заносится в информационном хранилище. Эта инфрмационная среда непосредственно взаимодействует с оборудованием (контроллер, радиомодуль и т.п.), тем самым реализуются функции системы.
- ПК - это некоторая "железка", которая должна выполнять именно те функции, проработка которых требуется в этом пункте. Следовательно, имеется факт подмены задания - вместо проработки задач модуля принятия решений точки сбора представлен компонент структурной схемы. Требуется именно обоснование функций системы и, как следствие - получение обобщенной функциональной схемы. То, что представлено на рис. 2, к обоб. функциональной схеме имеет весьма отдаленное отношение.
- Недостаточно четко проработан вопрос и идентификацией сетевых устройств и других объектов системы. Этот вопрос не должен решаться самотеком.
Вывод: п.1.2 требует доработки.
Рис.3 - "информационные связи" - непонятно его назначение. К задаче 1.3. Определение и обоснование структуры информационной подсистемы сети. Выявление важнейших регистров подсистемы, пояснение необходимых информационных связей он не имеет никакого отношения. Вывод - п.1.3 не выполнен.

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Краткие замечания к сообщению Ильи Минаева

Сообщение tor_root » 17 ноя 2011, 08:41

Обсуждаемое сообщение.
Илья!
Предлагаю следующее.
1. Добавить рисунок по структуре физического уровня.
2. Раскрыть все используемые аббревиатуры.
3. Добавить к рисункам подписи (там, где они отсутствуют).
4. Дополнить текст ссылками на рисунки.
5. Четко определиться с терминологией сетевых объектов (точка накопления, терминал, и т.д.), ввести соответствующие сокращения и их использовать в дальнейшем.
6. Доработать раздел описания сценариев. Не понятно, к какому уровню модели имеет отношение "Сценарий взаимодействия КУ" - объединять функции различных слоев в одно описание - предпосылка к последующей путанице. Поясню: если сценарий имеет отношение к верхнему уровню, то в нем должны быть представлены функции взаимодействия с датчиками (команда съема данных, опрос датчиков и т.п.), анализ поступающих от точки накопления команд и соответствующая реакция на них, подготовка сообщений для передачи. Если описание сценария имеет отношение к физическому уровню и части канального, то в нем могут быть представлены процедуры конкурентной борьбы, поиска сети и синхронизации с ней, собственно режимы работы физ. уровня: idle, активный и т.п. Где-то так.
7. Что есть "суперкадр"?

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Краткие замечания к сообщению Анохина Алексея

Сообщение tor_root » 17 ноя 2011, 09:39

Обсуждаемое сообщение.
Сообщение хорошо продуманное, но имеет на мой взгляд следующие недостатки.
1. Как и в работе Кирилла Лизунова, при проработке обобщенной функциональной схемы основное внимание уделено некоторым крупным сетевым объектам, терминалы как-то выпали из анализа - а это очень важная часть. На рис. 2 представлена структурная схема сети, но никак не функциональная - схема, объединяющая выполняемые задачи/функции системы, но не объекты, их реализующие!
2. Спорным является решение разделение части решаемых задач между контроллером и коммутатором. Для небольшой сети это явно избыточно. Логически разделение может иметь место, практически - нет: вспомните демонстрацию работы БС GSM на одном из занятий - объемный функционал сети был сосредоточен на ноутбуке в виде относительно небольшого программного модуля.
3. Отразить предполагаемые интерфейсы связи разнесенных в пространстве сетевых объектов (БС, контроллеров и коммутатора), т.е. каким образом предполагается обеспечить пересылку данных между ними. Указание связей на рис. 2 в виде стрелочки явно недостаточно.
4. Детали физического уровня при описании функций БС надо избегать - это цель следующего сообщения. Здесь надо рассматривать БС как "рупор" сети: некий "черный" ящик с возможностью управления: с одной стороны радиоинтерфейс, с другой - два интерфейса: управления и передачи данных. Задач БС можно выделить достаточно много, к примеру: переключение профилей, сборка/разборка пакетов, синхронизация, поддержка мобильности, борьба с многолучевостью, особенности FHSS и т.п.
5. Отсутствует четкая проработка идентификации сетевых устройств и др. объектов. Не рассмотрен вопросы идентификации сети, необходимости организации широковещательной передачи (причем уникальная для каждой БС)
6. Отсутствует проработка идеи ПО, в этом случае сильно возрастает роль фразы "некоторые измерительные процедуры" - этих 3-х слов явно недостаточно.
7. Считаю, что целесообразно ввести идентификаторы услуг системы - они пригодятся в будущем.
8. Непонятно, каким образом будет осуществляться привязка конкретных абонентов к терминалам, как будет заноситься/обновляться информация в информационной подсистеме.
9. Функциональные особенности системы, отраженные в п.1.1 и 1.2, должны быть какм-либо образом отражены в структуре информационной системы (к примеру, где хранится или как собирается информация, передаваемая по BCCH, как функция ПО отражается на инф. систему). Если предположить, что возможно функционирование 2 разных сетей в непосредственной близости, то каким образом они с т.з. инф. системы могут быть сконфигурированы?

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

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Краткие замечания к сообщению Панчук Владимира

Сообщение tor_root » 17 ноя 2011, 12:45

Обсуждаемое сообщение.
Владимир, прежде всего замечание по грамотности изложения - страдает орфография и пунктуация. Иногда при изложении наблюдается внезапное прекращение мысли и рождение новой. К примеру:
а. Каждому терминалу при регистрации в сети будет присвоен персональный идентификатор и индивидуальный ключ идентификации который он должен будет вводить при выходе в сеть Почему "выход в сеть" (околосетевой жаргон, может "подключение к сети", на крайний случай - "вход в сеть") и "он должен" - кто он и кому должен?
б. В ней будут хранится активные абоненты - уточните, как абоненты будут храниться в системе? В свежезамороженном виде?
в. Также необходимо чтобы терминал находился в пассивном режиме «спал» и включался только для передачи и приема данных когда точка доступа передает запрос. Слово "спал" по стилю как-то выпадает из предложения. Какой запрос ТД передает, на основании чего? Перед этой фразой, по всей видимости, должно находиться описание принципа построения сети, после чего будет следовать обобщенное описание сценариев обслуживания терминалов.
г. Это можно реализовать следующим образом: при появлении терминала в сети точка доступа сообщает терминалу когда будет происходить и период повторного опроса на желание передавать информацию либо на получение оной. Казнить нельзя помиловать. Расставьте знаки препинания. И старайтесь упрощать стиль изложения. Примерно тоже самое Если терминалу в заданное время не вышел из режима сна точка доступа исключает его из базы данных «активных терминалов». И такое безобразие практически в каждом предложении.
По остальному.
1. Практически напоминаю каждому, в том числе и Вам: правила оформления сообщений. Следовать буквально!
2. Рис.1 - это не то, во что Вам хотелось бы верить. Рис.1 - это не обобщенная функциональная схема, эта картинка дает общее представление о топологии сети, причем характеризуется низкой информационной содержательностью. Прочитайте разбор сообщения Кирилла Лизунова, там похожая проблема.
3. Аналогично, Рис.2 - это не имеет никакого отношения к информационной подсистеме сети. Это утрированное видение Вами сценария взаимодействия точки доступа - терминал.
4. Роль, задачи и функции сетевых объектов практически не раскрыты.
5. На будущее - предлагаю использовать термин "информационная подсистема" вместо БД. БД - это средство реализации информационной подсистемы.

По совокупности изложенного:
п.1.1 - отчасти выполнен, часть задач опущена.
п.1.2 - практически отсутствует
п.1.3 - отсутствует.

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Замечания к сообщению Сергея Андреева

Сообщение tor_root » 17 ноя 2011, 16:03

Обсуждаемое сообщение.
К сожалению тщательно подготовленный в течение продолжительного времени разбор сообщения был утрачен в процессе его отправки. Повторно делать эту работу не буду. Если коротко:
Все пункты, кроме п.1.5 содержат пустую или нецелевую информацию. Как пример:
Для связи с центром сбора информации и терминалов (радиомаяков) потребуется подключение всех устройств к общей сети, где передача организуется по радиоканалу в режиме on-line,тогда терминалы будут работать как обычные радиостанции в УКВ диапазоне. Цифровая информация будет передаваться с заданной скоростью терминала.
Вода, дети, мокрая, а солнышко - теплое...
К чему такие сведения - непонятно.

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

А вот это напоминает радиообращение директора из "Улитки на склоне" Стругацких. Тщательное скрытие информации под потоком банальностей.

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

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

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

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

Сетевой трафик - объём информации, передаваемой по сети за определённый период времени. Воспользуемся соединением Security Association (SA), которое предоставляет службы обеспечения безопасности трафика, передаваемого через него. Центр сбора и стеки узлов на каждой стороне хранят режим, протокол, алгоритмы и ключи, используемые в SA. Каждый SA используется только в одном направлении и реализует один режим и протокол.
Непонятно - к чему это? Что это за решение Security Association - какие-то обрывки идей, решений. Короче, куча-мала.


Структура информационной подсистемы делает возможным обмен данными между центром сбора информации и терминалами в двунаправленном режиме, т.е. с возможностью не только отправки данных, но и запроса центром результатов последних зафиксированных данных терминалами, радиообмен ведётся на определённой скорости(9600 бод, символьная скорость).
Как реализуется двунаправленный обмен? Откуда определенность в скорости передачи? Такое ощущение, что читаю заключение пояснительной записки.

Рис.3 - это не информационная подсистема. 527 раз уже было сказано, что подразумевается под инф. системой. Демонстрируете повтор ошибок Ваших товарищей, да и собственных тоже.

Проблема множественного доступа - как отмечалось выше, система сбора параллельных данных организует для каждого измерения канал, и если информация с объектов приходит на терминал одновременно, то следует применить TDMA (множественный доступ с разделением по времени). Каждый датчик будет способен использовать весь возможный минимальный диапазон частот, но в течение короткого периода времени.
Этим сакраментальным фразам посвящены п.1.1-1.3. Вы же уложились в 2 предложения...

Рис.4 - не соответствует описанию в тексте. Что такое "hardware address" и каков его смысл появления. На основании каких задач из предшествующих пунктов? Аналогично по всему остальному содержимому. Необходимо отразить влияние мобильности терминалов на уровни модели и подготовить рис. по физ. уровню.

Содержимое п.1.5 требуется дополнить пояснением примера оперативной работы сети. Не отражен режим начального конфигурирования системы - по всей видимости это должно быть.

tor_root
Сообщения: 2182
Зарегистрирован: 15 фев 2011, 22:44

Замечания к сообщению Дарьи Зенкиной

Сообщение tor_root » 22 ноя 2011, 13:13

Обсуждаемое сообщение
1. Требуется сформулировать список основных услуг, предоставляемых сетью.
2. Сформулировать задачи Т и ТД с точки зрения назначения сети
3. Провести анализ системы на предмет возможности возникновения коллизий, сделать выводы.
4. Решить вопрос с идентификацией сетевых участников, провести анализ возможности разворачивания в одном месте нескольких подобных сетей - какие могут возникать проблемы и каким образом они могут быть решены. Как следствие - соответствующим образом должны быть скорректированы функциональные схемы.
5. Рис. 2 - пояснить назначение сетевого контроллера.
6. Уточнение: рис.4 - это информ. система ТД. В Т некоторое подобие ИС также должно быть. Что из себя может представлять ИС в составе Т?


Вернуться в «Курсовой проект»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя