Регистрация | Последние сообщения | Персональный список | Поиск | Настройка конференции | Личные данные | Правила конференции | Список участников | Top 64 | Статистика раздела | faq | Что нового v.2.3 | Чат
Skunk Forum - Техника, Наука, Общество » АСУТП »
Диспетчеризация . Муки выбора (С) (страница 1)

Версия для печати (настроить)
Страницы: 1 2

Новая тема | Написать ответ

Подписаться

Автор Тема:   Диспетчеризация . Муки выбора (С)
pap
Junior Member

Сообщений: 1
Откуда: екатеринбург
Регистрация: Сентябрь 2008

написано 30 Сентября 2008 09:28ИнфоПравкаОтветитьIP

Цель мониторинга (учет тепла и ГВС в ЖКХ, соцсфере ,промышленные предприятия, баланс источника)
- снижение стоимости эксплуатации (на 1 сотрудника 70-100 УУ или 700-1000 ед.оборудования) при непрерывной и достоверной работе УУ (99%)
- исключение на 100% из процесса формирования отчетов и БД человеческого фактора и создание доверительных отношений между потребителем и поставщиком
- постоянный контроль достоверности показаний УУ и качества потребления
- работа УУ (90%) с момента включения отопления, остальное в течении недели
- мониторинг оборудования УУ в реальных условиях эксплуатации и в первую очередь расходометрии (в результате отказались применять оборудование многих производителей , а также методов измерения, т.к. происходит обман ПОСТАВЩИКА на существенные деньги и недоверие с его стороны)
и т.д.
Инфраструктура - любая, зависит от кошелька заказчика, поставленных задач (и подкрепленных деньгами) , территориальную возможность или исторически используемую (Газпром, большая энергетика и т.д.)На ЖКХ используем изернет (400 домов) проблем ни с "последней милей" не имеем, ни до подключения узла УУ, в соцсфере - GSM, GPRS или АТС (особенности !)
ПО верхнего уровня - открытая архитектура.

А теперь немного о некоторых заблуждениях, особенно касающиеся ПО у потребителя (ЖКХ, соцсфера и т.д.) по учету энергоресурсов

1.Лучший и универсальный инструмент ПО - Скада системы

Скада-системы предназначены для получения оперативной информации , как правило технологически взаимосвязанной (например котел или прокатный стан) и где архивы идут от оперативки. Последние скады имеют возможность работать с архивной локальных объектов (УУ, особенно коммерческие), но зачем тогда продукт заточенный на оперативку ? Купим вольво и будем возить навоз, а может лучше трактор с тележкой - и функциональней и намного дешевле.

2.Применять только водо-газосчетчики обязательно имеющие ОРС-сервер для унификации нижнего уровня

ОРС -сервер, да нужная вещь особенно там где заказчик ,в рамках своих задач ,определил ,пускай разнообразный парк приборов ,но ограниченный и озаботился о быстрой их замене. И это, как правило, опять привязано к оперативке и единичному параметру.А ЖКХ, соцсфере один чиновник что-то пролоббировал ,а потом подарил или передал УК (как правило бестолковой) или школе, устроив зоопарк,при этом каждый год другое. А тепло-газосчетчики - это куча разных датчиков и расчетных параметров ,и ломается в основном первичка (расходомер,давление, термометр и к ОРС серверу отношение не имеющее ). И для чего спрашивается нужен ОРС-сервер в данных условиях?

3.SQL сервер ORACLE или R3 - престижно и круто
SQL сервер ORACLE или R3 - наверно таким системам ,как Газпром, ТГК, ОГК без такого рода продукта просто не обойтись.Но остальным зачем ?Разница в цене относительно "бюджетной" продукции на 2-3 порядка (ни в разы!). При этом дополнительно обуза - наличие многочисленной и высокооплачиваемой группы поддержки. А результат тот же ,только потенциал продукта используется на пару процентов.

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

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

6. По верхнего уровня должно делать все
А зачем? Если есть структура БД , то ты ,как пользователь независим и деньги будешь платить при решении поставленной и объективно необходимой задачи когда надо и в объеме реально соответствующиее сделанной работе.А сегодня многие потребители ПО верхнего уровня как рыба на крючке.Плюс столько стандартных , обкатанных и недорогих программ.

7. И самое интересное .У меня зоопарк по приборам учета и я все это подключу к диспетчерской через инженерный терминал.
Очень популярно у больших систем - большие энергетики, структуры ЖКХ и соцсферы и прочие. Сколько не моделировал обоснованность такого технического решения ,но смог прийти только к одному выводу, но это не тот форум , необсуждаю. На эту тему можно написать целую статью, но ограничусь минусами, а плюсов я пока не знаю
- дорого ,притом в разы ,фактически это системный блок в промышленном исполненении с кучей всяких интерфейсов
- излишняя избыточность(предусмотрены все ситуации , а используются процентов 10
- при малейшем изменении версии тепло-газосчетчика все обкатывать с выездом на каждый объект
- полная зависомость от интегратора этого инженерного терминала
- сложность в настройке и однозначность в передачи нужного параметра , а также возможности контроля качества работы персонала при многоступенчатой передаче
- возможность злостного искажения информации в интересах какой-либо стороны
- и главное , тот кто ведет производственную деятельность и заинтересован в данной информации в перспективе будет оплачивать эту информацию, или что еще хуже, за работу отвечает он , а информацией и деньгами владеет кто-то третий .

8. Если работает 5 приборов в сети , то и остальное любое количество будет работать (главное есть RS-232 , 485 )
После появления 50 УУ (а это важно и кто знает Windows, понимает о чем речь) столкнулись с системными проблемами ,пришлось переделовать много, вт.ч. принципиальных ,вещей (и первую очередь тепло-газосчетчик) ,100 УУ- решали проблемы, много решили проблем после 350 штук.Но в базе ПО и тепло-газосчетчика все инструменты имелись и решение не вызвало системных изменений.Посмотрели как это реализовано у других , особенно по контроллерам энергоучета...Каждый выкидывает деньги по своему.
А многие тепло-газосчетчики никогда не работали в информационных системах и не будут (ну сделали их как локальные) или будут ,но после массы переделок или затрат денег, сопоставимые с стоимостью УУ (наблюдаю вживую , особенно в большой энегетике)

Пирогов А.П.

ColdFire
Member

Сообщений: 313
Откуда: Россия
Регистрация: Ноябрь 2004

написано 30 Сентября 2008 10:18ИнфоПравкаОтветитьIP

И что это?

[Это сообщение изменил Dmitry M. Gaidash (изменение 30 Сентября 2008 12:51).]

pap
Junior Member

Сообщений: 2
Откуда: екатеринбург
Регистрация: Сентябрь 2008

написано 30 Сентября 2008 12:43ИнфоПравкаОтветитьIP

Размышления специалиста, который знает что ему надо в результате , но иногда сомневается в правильности выбранных инструменов.А за спиной десятки систем диспетчеризации с непрерывной работой с 1994г и по сегодня и с количеством узлов учета, в системе, от 50 до 400 в сфере ЖКХ, соцсфере, крупные промышленные предприятия и нфраструктуре источников. Писал для тех кто мучается в выборе и не владеет данной темой, но прекрасный специалист в теплотехнике,метрологии, энергетике и т.д. И нужна ему синица в руках ,а не журавль в прекрасном далеко.

ColdFire
Member

Сообщений: 319
Откуда: Россия
Регистрация: Ноябрь 2004

написано 30 Сентября 2008 12:52ИнфоПравкаОтветитьIP

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

pap
Junior Member

Сообщений: 3
Откуда: екатеринбург
Регистрация: Сентябрь 2008

написано 30 Сентября 2008 14:40ИнфоПравкаОтветитьIP

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

Dmitriy Chukichev
Junior Member

Сообщений: 7
Откуда: РФ, Москва
Регистрация: Март 2006

написано 30 Сентября 2008 15:32ИнфоПравкаОтветитьIP

pap
- А что вместо СКАДЫ - к-н "самопис" или веб? Часто учет совмещают с классической диспетчеризацией, с контролем текущих параметров - тогда только СКАДА. К тому же наблюдал попытки разработчиков нескольких ПТК для учета доработать свой софт верхнего уровня до функционала СКАДА - не хочу продолжать.
- В части нежелания разработчиков ПТК дорабатывать свой софт под другие приборы - есть и иные причины.
- Мы в России - куда уж без лоббирования Но не всегда возможно установить прибор желаемого типа (метода измерения) из-за неидеального места установки, а перестраивать технологию - денег нет...
- Не все заказчики, точнее их, отдельные представители заинтересованы в снижении цены...

А где-то есть в Инете описание одного из ваших проектов с конкретикой?

ColdFire
Member

Сообщений: 320
Откуда: Россия
Регистрация: Ноябрь 2004

написано 30 Сентября 2008 15:50ИнфоПравкаОтветитьIP

Я не о том, что есть какие-то проблемы с подключением приборов учета в систему. Я про то, что нормальные системы строить просто не на чем. На рынке туча приборов, более или менее распространенных, но при этом везде те или иные косяки. Систему построить как два байта переслать - подпорка на подвязке. А вот замечания по сути ваших постов:

1. Я слышал, что есть места, где на SCADA сделаны системы учета (но сам живьем не видел). Они работают и слава богу. Потому как любая более-менее крупная система учета живет до тех пор, пока ею занимаются. Уйдут понимающие в деле люди - алес капут через пару месяцев. С другой стороны соглашусь, что городить систему учета на софте, предназначенном для HMI - так же нелепо, как писать складской учет на Delphi (то есть можно, но 1С все равно не получится, а времени будет убито уууу). С третьей стороны, специализированный софт для систем учета недешев и соизмерим по цене со SCADA, и даже превосходит их. Дешевый софт как сыр в мышеловке - кому он нафиг нужен без поддержки, а платить за поддержку кто будет ?

2. Или платите за OPC (DA/HDA), или платите разработчику софта системы учета за разработку того же нативного драйвера.
Чей лучше - в наших условиях очень туманный вопрос.

3. Если в требованиях прописан оракл, значит будет оракл. Только у нас в одном тендере могут соревноваться 1С и R3 и победить 1С. Наличие группы техподдержки в общем случае обязательно - если в окрестностях крупных городов еще более-менее с персоналом, что в каком-нибудь мухосранске группа туканов убьет любое оборудование и софт в кратчайшие сроки. Причем стандартизация есть большой плюс - винегрет технологий тоже не на пользу. Если заказчик готов платить деньги - почему бы и нет.

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

5. Реагировать на каждый чих каждого заказчика - никакого бюджета не хватит. Мы, например, коммерческая организация и благотворительностью не занимаемся. Со стороны заказчика должно быть понимание, что любое желание за его деньги. Соответственно, шаги оцениваются - купить левый дешевый прибор и заплатить разработчику, или купить нормальный и получить драйвер в комплекте. Чем крупнее организация-разработчик, тем более она неповоротлива, больше накладных расходов и т.д., проще потерять одного заказчика. Никакого лоббизма - просто здоровый эгоизм. На этом подходе кормится много мелких фирмочек, подбирающих объедки с барского стола. Уж извините за тон - вопрос лишь в величине объедков, все мы пасемся на каких-то уровнях...

6. Такое есть, но не так много. С другой стороны, есть типовая процедура - задание-реализация-сдача. Получил задание, реализовал в соответствии с ним, сдал, получил деньги. ПО либо делает все положенное, а на остальное предоставляет инструмент для его реализации. Разгребать потребности всех и вся никаких денег и времени не хватит.

7. Ничего не понял, так что комментировать не буду.

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

Добавление от 30 Сентября 2008 15:54:

Dmitriy Chukichev
Очень странное совмещение, тем более что как правило у этой информации разные потребители. Есть варианты со шлюзованием одного в другое.

Dmitriy Chukichev
Junior Member

Сообщений: 8
Откуда: РФ, Москва
Регистрация: Март 2006

написано 30 Сентября 2008 19:13ИнфоПравкаОтветитьIP

ColdFire
Согласен с большинством Ваших доводов. Но все же интересно - на верхушке что? Мы делали несколько систем на всех перечисленных вами вариантах, в разных масштабах (и готовые ПТК, и самописки крохотные, и SCADA/HMI). Идеального решения, имхо, нет. Везде есть ньюансы. И две задачи - визаулизация и прикладные задачи работы с БД. А совмещение реально было, хотя, согласен, не кузяво это все - Заказчик хотел видеть показания токов и напряжения, считываемых со счетчика на однолинейках в Скаде. Причем однолинейки должны отображать состояние коммутирующих аппаратов (такой вот симбиоз АСКУЭ и АСОДУ). И тут же - Оракловая база для бизнес-приложений. Он же деньги платит, он девушки и танцует. Само собой, никоим образом не проповедую данное решение, но - была задача, её решили. Как Вы правильно заметили,"Когда заказчики научатся включать мозги перед тем, как покупать непонятно что, а также формулировать
внятные технические задания, будет хакуна матата".

Павел Мощицкий
Member

Сообщений: 2282
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 30 Сентября 2008 21:15ИнфоПравкаОтветитьIP

pap
Не очень понятно, откуда взяты некоторых заблуждениях?
1. Никто и не спорит, что задачи ЖКХ не совместимы с задачами, например, энергоблока ГРЭС. Но тут тоже есть оперативная информация. Почему считается, что оперативная, это с шагом раз в 100 мс или секунду, а почему не учитывать шаг в месяц?
2. Ну тут автор имел в виду другое ColdFire, как я понимаю. Нужны ли вообще драйвера и диспетчеризация нижнего уровня, как факт? Я сейчас такой факт наблюдаю в Израиле. В этой стране нет газопроводов и т.д. В каждый дом ставится из какого-то расчёта какое-то кол-во газовых баллонов, которые в РФ есть ещё в деревнях и на дачах. Так вот. С шагом в два месяца сотрудник компании приезжает в каждый дом и смотрит показания счётчика для выставления счёта и хватит ли в каждом баллоне газа ещё на два месяца. Нет, заменяет, т.к. приезжает на грузовой машине с этими баллонами. С водой и электричеством аналогичное. Счётчики проверяются раз в два месяца плюс минус неделя. Россия идёт тоже к повальной установке счётчиков. Вы предлагаете подобный метод?
3-4.Ну тут я не в курсе, кто так считает. Похоже, идёт банальное лоббирование. Я бы вообще бы использовал бы специализированные СУБД, заточенные под ЖКХ со своими протоколами и структурой из расчёта скорее не скорости, её в этой области нет, а секретности данных. В РФ это запросто приведёт к шантажу.
5. Ну это банальное лоббирование, которое свойственно коррупмированой стране. Где живёте, то и имеете и приходится инженеры отвечать за решения начальства.
6. Тут нужно понять, что Вы считаете По верхнего уровня? Или ПО АСУ или ПО АСУ ТП?
7. Ну тут как проблема лоббирования, так и проблема автоматизации частями. Данная проблема есть и когда системный интегратор приходит на работающий завод или другой производственный объект. Даже есть преобразователи из одного протокола в другой, разработанные по этой причине.
8. Главная проблема - проблема адаптации имеющегося. Не понял, чем п.8 отличается от 7? Он скорее, как его частный случай.

ColdFire
Member

Сообщений: 323
Откуда: Россия
Регистрация: Ноябрь 2004

написано 02 Октября 2008 10:34ИнфоПравкаОтветитьIP

Павел Мощицкий
1. Задачи ЖКХ, я бы так сказал, задачи управления энергоблоком могут и переплюнуть в плане информационной емкости - по энергоблоку-то оперативные тренды всего-ничего хранить надо, а коммерческие данные могут и 10 лет потребовать. Шаг в месяц - это конечно хорошо (в Европе так и делают), но в российских условиях маловато будет, получасовки или в районе того смотреть надо. Небаланс иначе не выявить будет, а он есть и невдолбенный. ГУП ТЭК называет неофициальную цифру порядка 15%, в то время как должен он быть в прелелах 5-7%, остальное банально воруют.
2. Есть AMR, есть электронный биллинг, есть сервисные функции - с одной стороны это разные вещи, с другой стороны скрестить их в одном приборе (системе) логично. Сейчас в воздухе вокруг бытового учета витают идеи единого учета, то есть общей электроники, обслуживающией и воду, и газ, и электричество, и тепло - чтобы деньги на приборах сэкономить. Но дальше одиночных пилотных проектов дело не пошло. Сильно под вопросом юридическая и метрологическая сторона, да и с достоверностью не все гладко. Короче, пока ТСЖ нормально не пойдет, а цена потерь не станет соизмеримой с ценой системы, дело никуда не пойдет.
3. Насчет 3 с лоббированием не уверен - ну если оракл, то это конечно перебор. Между тем требование поставить именно MS SQL встречается часто, просто потому, что у заказчика есть обученный персонал, и, возможно, скидки от поставщика.
А с 4 - это часто коммерческий интерес производителя, чтобы взяв приборы, взяли софт у него же. В нынешних условиях во многих случаях можно выбрать другие варианты, где все открыто.
5,7. Возможно, но необязательно именно лоббирование. Я уже писал - у компании-разработчика софта есть тоже свои коммерческие интересы. Нам, например, глубоко фиолетово что будет стоять у заказчика. С другой стороны, мы отвечаем за работоспособность нашей системы, и естественно что мы будем стараться отговорить клиента от покупки откровенно поганых приборов - заколебемся иначе с сервисом и саппортом. С третьей стороны, есть крупные компании, которые зарабатывают именно на массовой продаже софта - разрабатывать персональный драйвер под конкретного заказчика им просто невыгодно (даже за большие с точки зрения обывателя деньги). Обратите внимание - в определенный момент фаза разработки переходит в стадию продаж, и становится более пассивной к запросам. На рынке есть примеры... причем это не хорошо и не плохо, просто законы рынка.

Dmitriy Chukichev
Позволю себе влезть в вопрос другому человеку. Веб - чудесная технология, особенно для задач ЖКХ. Когда у вас становится больше десятка пользователей, которым нужно что-то постоянно менять, начинается геморрой с саппортом. С формальной точки зрения, можно и гибрид делать - когда сбор данных идет одним софтом, а представление и формирование отчетов - чем-нибудь другим, необязательно самописным - есть масса серверных исполнений отчетных генераторов.
Кстати, а что вы имеете против самописа ? Все продукты в какой-то момент проходили стадию активной разработки. Почему на один продукт (например, российский) все будут морщиться и показывать пальцем "мол мы эту наколенщину ставить не будем", а на другой (допустим, импортный) молиться, хотя где больше багов и хуже саппорт еще бабушка надвое сказала. Вот что в России плохо, так это со стабильностью, не только в области софта. Сегодня успешная компания-разработчик завтра исчезнет с рынка под предлогом, или выпустит нечто новое и несовместимое, а по старому софту прекратит поддержку.

И это не только с софтом. В магазинах массово продается электронное барахло типа "умный дом". Качество никакое, цена не фонтан, но покупает же кто-то, раз продается. Зато лейбл "made in USA".

Мы тоже делали системы разных видов и на разных средствах. В итоге мы пришли к тому, что ставим свой верх (разработка идет уже очень давно), а базу данных на выбор - или бесплатную для маленьких-средних систем, или за деньги заказчика из разумного списка. Приборы - как я уже писал, нормальных приборов нет, поэтому всегда получается компромисс. То есть есть хорошая первичка, но это только половина дела. Где-то мы делаем проекты "под ключ", где то продаем только софт. Другое дело, что есть заказчики, которым объясняешь-объясняешь, они все равно выберут какую-нибудь лажу, а потом ноют что выбранные приборы в систему вообще никак не завести. Если нужны диспетчерские функции - опять же выбор. Есть встроенные средства визуализации (в том числе с трансляцией в веб), есть OPC-сервер наружу, а там что угодно.

Dmitriy Chukichev
Junior Member

Сообщений: 9
Откуда: РФ, Москва
Регистрация: Март 2006

написано 03 Октября 2008 13:52ИнфоПравкаОтветитьIP

Ничего абсолютно не имею против самописа. Если руки разработчика из нужного места растут - возможно это самый эффективный вариант решения вопроса.
А где можно посмотреть про Ваше решение или проекты?

ColdFire
Member

Сообщений: 326
Откуда: Россия
Регистрация: Ноябрь 2004

написано 03 Октября 2008 14:10ИнфоПравкаОтветитьIP

Dmitriy Chukichev
Это вы к кому ?

Павел Мощицкий
Member

Сообщений: 2291
Откуда: Израиль. Бат-Ям
Регистрация: Январь 2004

написано 03 Октября 2008 18:30ИнфоПравкаОтветитьIP

ColdFire
в российских условиях маловато будет
Небаланс иначе не выявить будет
Хороший способ борьбы с воровством. Только что дороже обойдётся, воровство или борьба с ним?
2. Понял. Не думаю, что решится, боюсь, что скоро даже на уровне ЖКХ за них будут отвечать разные ведомства, как в Европе.
3. Ну если в одном месте боремся с воровством, а в другом нет, то какой тут бизнес получается?
разрабатывать персональный драйвер под конкретного заказчика
Ну фирмы-разработчики из России это делают вместо производителя, пытаясь с ними договориться о OEM-партнёртстве. Есть, которые пытаются защититься тем, что сами стараются занять все уровни и в разработке и в производства металла. Но есть и те, о которых Вы говорите, но это не тенденция, если именно зарабатывают именно на массовой продаже софта.

Но это разговор уже не технической, а коммерческой плоскости. Если Вы в этом понимаете, давайте поговорим.

ColdFire
Member

Сообщений: 327
Откуда: Россия
Регистрация: Ноябрь 2004

написано 03 Октября 2008 23:15ИнфоПравкаОтветитьIP

Павел Мощицкий
А проблему в ЖКХ один черт дешево не решить. Море счетчиков не проверялись и не поверялись со времен царя гороха. А с текущим уровнем воровства окупаемость получается неплохая.

Ваш ответ:

Коды форума
Смайлики


Ник:    Пароль       
Отключить смайлики
Страницы: 1 2

Все время MSK

Склеить | Разбить | Закрыть | Переместить | Удалить

Новая тема | Написать ответ
Последние сообщения         
Перейти к:

Свяжитесь с нами | skunksworks.net

Copyright © skunksworks.net, 2000-2018

Разработка и техническая поддержка: skunksworks.net


Рейтинг@Mail.ru Яндекс.Метрика