SCL хорош хотя бы тем, что позволяет косвенно адресовать элементы массивов. И компилируется потом в такую кашу на STL, что желающие стащить проект непосредственно из контроллера потом долго в нём ковыряются :)
У сименсов наработка на отказ не хорошая. Она отличная.
Мне ещё ни разу не доводилось видеть сдохший не от внешних причин контроллер. Да что там, мне даже ни разу не доводилось видеть непредсказуемо глючащий контроллер. Все ошибки обычно в конце концов находились в коде проекта, либо были связаны с электрическими проблемами (плохой контакт, жуткие наводки на легкомысленно запущенный на 1.5 мбитах полукилометровый Profibus и т.д. :)
Из отечественных, навскидку, ОВЕН и ТЭКОН через OPC.
По Modbus TCP цепляли много чего (Schneider Electric, например).
Вообще там в папочке bin много всяких .chn-файлов разнообразных.
Не спорьте с официальными Siemens Solution Partner :)
1. Step 7 действительно в общем смысле обозначает «седьмое поколение» сименсковских промжелезок. Однако в официальных каталогах контроллеры серий S7-300, S7-400 и т.д. нигде не обозначаются как «Step 7-300». Так что Step 7 — это только софт для программирования и настройки железа.
2. Если быть точным — внутри контроллеров S7 начиная с 300й серии (а теперь и с 1200й) бегает полноценная ОС реального времени. Так что процесс программирования контроллера по сути ничем не отличается от процесса установки новой программки в айфончик из аппсторчика. Никаких «программируемых чипов» в общепринятом среди эмбеддеров смысле нет.
3. Никаких «процессов» код червя в контроллере не «убивает». Правильнее было бы написать «нарушает производственный процесс». А если уж совсем точным быть — червь нарушает обработку системного 100 мс таймера (ЕМНИП), непредсказуемо (на первый взгляд) меняя ход работы программы.
Я пока собрал 4-коптер на плате Hobbyking V2 (она же плата от KaptainKuk). На ней, как я понял, только 3 гироскопа. Соответственно, она не корректирует медленные наклоны, когда угловое ускорение по осям близко к нулю, и коптер, повисев секунду-другую, начинает плавно сваливаться в какую-нибудь сторону.
Монстры RC, конечно, запросто корректируют это вручную с аппы, но мне хочется, чтобы коптер хоть как-то зависать умел. Поэтому хочу поменять систему управления на нунчаку от Wii с имеющейся у меня платой AVR-Crumb128 (баро, сонар и GPS в перспективе).
В спецификации на GPU чип raspberry pi сказано H.264 decoding/encoding. Так что видео с камер может быть он и в состоянии писать. Сам сейчас разбираюсь с этим…
SCADA это же «supervisory control and data acquisition». Т.е. высокоуровневый контроль и сбор данных. Никто не делает управление исполнительными механизмами непосредственно от ПК с SCADA-системой :)
И как раз НЕиспользование SCADA аргументировано для малых объектов, где можно обойтись парой кнопочек и цифровых индикаторов (как максимум — операторской панелью с графическим экранчиком).
А я с прошлого года воюю с пингвиновым рейдом.
Вводное — Gigabyte GA-P55A-UD4, диски WD Caviar Black 3 штуки 2 TB.
Задача — сделать RAID5 в линуксе. Основное применение — хост для зоопарка виртуалок в VMWare Player.
Сначала я создал рейд-массивы средствами материнки для Ubuntu 10.10. Но это получился FakeRAID, утилиты для работы с которым в линуксе официально в стадии alpha-версии. Посему dmraid не поддерживает таблицу разделов GPT (а таблица типа MSDOS не тянет массивы больше 2 ТБ). kpartx поддерживает, /dev/mapper/ инициализируется, всё вроде пашет, но через неделю активной работы файловые системы почему-то рассыпаются в хлам.
Затем не глядя был куплен хардварный рейд-контроллер Promise Fasttrak TX4660. Оказалось, что для него есть драйверы только для редхата и сусе. Ну что ж, удалось завести драйверы в CentOS 5.5 (в сравнении с убунтой эта ось как win95 к winxp, такой олдскул :). Работает вроде стабильно, но после убунты в центоси работать непривычно (шрифты — ужасужас, грузится минут пять и т.д.), да и драйвер сыроват, периодически плюётся ASSERT'ами в сислог. И почему-то оооооочень долго монтируются разделы. Скажем, 3.6 ТБ reiserfs минуты на две заставляет задуматься mount. А если тыкнуть кнопку reset, то перемонтирование разделов после такого аварийного завершения растягивается минут на 10.
Сейчас уже больше склоняюсь к тому, чтобы выкинуть промис и поставить убунту на LVM с SoftRAID. От системы не требуется супер-скорости. Нужна отказоустойчивость и поддержка одного мегараздела на 3+ ТБ для примерно сотни образов виртуальных машин с разными конфигурациями, которые должны быть всегда под рукой, ибо в нашей работе зачастую до 4х совершенно любых из имеющихся образов запускаются одновременно.
За инструкциями червяк стучался на следующие сайты: www.mypremierfutbol.com www.todaysfutbol.com
домены зарегены анонимно. на момент изучения антивирусниками DNSы указывали в совершенно «левые» места…
Приятно видеть специалиста, но я всё же рекомендую внимательно читать первоисточники, а не вольные пересказы журналистов (даже у Берда Киви в материале полно ляпов).
Мои 5 риалов:
1. Червь был заточен под конкретный PLC (или группу однотипных PLC) конкретного производства. У разработчиков явно была копия «хардвари» и «блоков» проекта Step7 атакуемого производственного объекта.
2. Червь вполне мог пролезть на «инженерную станцию», ибо зачастую эти станции — просто ноутбуки разработчиков, которые на них что только не творят в свободное время (и игры, и интернет). Мой ноут тоже такой :), недавно только закупили специализированный ноутбук SIMATIC Field PG, на котором соблюдаем «карантин». Впрочем, мне пока на опасных производствах не доводилось работать :)
3. Червь загружает вредоносный код в PLC в момент его программирования с инженерной станции путём перехвата трафика между станцией и PLC (заодно червь перехватывает обратный трафик и скрывает свой код). Таким образом, все пароли на проект идут лесом.
4. Если с незаражённой станции попытаться глянуть зараженный червем блок в PLC, то Step действительно ругнётся, что блоки в локальном проекте и в PLC не совпадают. Вот только очень редко другой инженер при этом откроет блок из «онлайна» (из PLC), чтобы посмотреть чего там не то, а скорее пнёт другого инженера (с заражённым ноутом), чтобы тот внёс нужные изменения или слил свежую версию проекта (заражённую червем ;). Да и вообще, как правило, при работе над сложной системой несколько разработчиков делают каждый свой кусок, а блоки, отвечающие за последовательность работы программы в целом пишет более опытный мега-инженер, настолько уверовавший в своё всемогущество, что позволил себе днём ранее почитать на своём ноуте свежее ТЗ, которое какой-то неизвестный местный притащил ему на флешке.
дисклеймер: всё вышеописанное является вымыслом, все совпадения с реальностью случайны и не имели место в действительности :)
так в том-то и дело, что у разработчиков «стухнета» наверняка был проект Step7, на который они и нацеливались.
вот, честно признаюсь, у меня на рабочем ноуте свалка проектов контроллеров (вплоть до нескольких 400й серии) со многих предприятий. атомных станций, правда, нет :)
не исключено, что некий атакуемый проект (не обязательно бушеровский) был украден из ноутбука (или вместе с ноутбуком) одного из разработчиков аналогичной моей степени раздолбайства :)
А вот эксперт www.langner.com/en/ пишет, что stuxnet также «заточен» и под Step7. Перехватывая процесс программирования PLC, червяк подсовывает туда свой код, и наоборот — при чтении содержимого некоторых блоков червяк также перехватывает данные и скрывает своё существование.
Я просто по работе слегка знаком с сименсовским промышленным оборудованием (сертификаты Step7 и WinCC, а также статус Siemens Solution Partner :)
Мне ещё ни разу не доводилось видеть сдохший не от внешних причин контроллер. Да что там, мне даже ни разу не доводилось видеть непредсказуемо глючащий контроллер. Все ошибки обычно в конце концов находились в коде проекта, либо были связаны с электрическими проблемами (плохой контакт, жуткие наводки на легкомысленно запущенный на 1.5 мбитах полукилометровый Profibus и т.д. :)
Вот настоящий LAD из Step 7, например:
creator.bcsoft.org/temp/lad.png
Кусочек программы, тоже управляющей неким рельсовым механизмом :)
По Modbus TCP цепляли много чего (Schneider Electric, например).
Вообще там в папочке bin много всяких .chn-файлов разнообразных.
Или надо «огласить полный список, пожаллста»?
1. Step 7 действительно в общем смысле обозначает «седьмое поколение» сименсковских промжелезок. Однако в официальных каталогах контроллеры серий S7-300, S7-400 и т.д. нигде не обозначаются как «Step 7-300». Так что Step 7 — это только софт для программирования и настройки железа.
2. Если быть точным — внутри контроллеров S7 начиная с 300й серии (а теперь и с 1200й) бегает полноценная ОС реального времени. Так что процесс программирования контроллера по сути ничем не отличается от процесса установки новой программки в айфончик из аппсторчика. Никаких «программируемых чипов» в общепринятом среди эмбеддеров смысле нет.
3. Никаких «процессов» код червя в контроллере не «убивает». Правильнее было бы написать «нарушает производственный процесс». А если уж совсем точным быть — червь нарушает обработку системного 100 мс таймера (ЕМНИП), непредсказуемо (на первый взгляд) меняя ход работы программы.
Я пока собрал 4-коптер на плате Hobbyking V2 (она же плата от KaptainKuk). На ней, как я понял, только 3 гироскопа. Соответственно, она не корректирует медленные наклоны, когда угловое ускорение по осям близко к нулю, и коптер, повисев секунду-другую, начинает плавно сваливаться в какую-нибудь сторону.
Монстры RC, конечно, запросто корректируют это вручную с аппы, но мне хочется, чтобы коптер хоть как-то зависать умел. Поэтому хочу поменять систему управления на нунчаку от Wii с имеющейся у меня платой AVR-Crumb128 (баро, сонар и GPS в перспективе).
Есть такое вот видео моего прототипа: www.youtube.com/watch?v=lg9BNtJFJXs
И как раз НЕиспользование SCADA аргументировано для малых объектов, где можно обойтись парой кнопочек и цифровых индикаторов (как максимум — операторской панелью с графическим экранчиком).
штатный браузер там же — 51/100
cyanogenmod на motodefy, как уже отмечено выше, opera — 100/100, штатный — 95/100
Вводное — Gigabyte GA-P55A-UD4, диски WD Caviar Black 3 штуки 2 TB.
Задача — сделать RAID5 в линуксе. Основное применение — хост для зоопарка виртуалок в VMWare Player.
Сначала я создал рейд-массивы средствами материнки для Ubuntu 10.10. Но это получился FakeRAID, утилиты для работы с которым в линуксе официально в стадии alpha-версии. Посему dmraid не поддерживает таблицу разделов GPT (а таблица типа MSDOS не тянет массивы больше 2 ТБ). kpartx поддерживает, /dev/mapper/ инициализируется, всё вроде пашет, но через неделю активной работы файловые системы почему-то рассыпаются в хлам.
Затем не глядя был куплен хардварный рейд-контроллер Promise Fasttrak TX4660. Оказалось, что для него есть драйверы только для редхата и сусе. Ну что ж, удалось завести драйверы в CentOS 5.5 (в сравнении с убунтой эта ось как win95 к winxp, такой олдскул :). Работает вроде стабильно, но после убунты в центоси работать непривычно (шрифты — ужасужас, грузится минут пять и т.д.), да и драйвер сыроват, периодически плюётся ASSERT'ами в сислог. И почему-то оооооочень долго монтируются разделы. Скажем, 3.6 ТБ reiserfs минуты на две заставляет задуматься mount. А если тыкнуть кнопку reset, то перемонтирование разделов после такого аварийного завершения растягивается минут на 10.
Сейчас уже больше склоняюсь к тому, чтобы выкинуть промис и поставить убунту на LVM с SoftRAID. От системы не требуется супер-скорости. Нужна отказоустойчивость и поддержка одного мегараздела на 3+ ТБ для примерно сотни образов виртуальных машин с разными конфигурациями, которые должны быть всегда под рукой, ибо в нашей работе зачастую до 4х совершенно любых из имеющихся образов запускаются одновременно.
Что посоветуете?
www.mypremierfutbol.com
www.todaysfutbol.com
домены зарегены анонимно. на момент изучения антивирусниками DNSы указывали в совершенно «левые» места…
Как будем искать?
Мои 5 риалов:
1. Червь был заточен под конкретный PLC (или группу однотипных PLC) конкретного производства. У разработчиков явно была копия «хардвари» и «блоков» проекта Step7 атакуемого производственного объекта.
2. Червь вполне мог пролезть на «инженерную станцию», ибо зачастую эти станции — просто ноутбуки разработчиков, которые на них что только не творят в свободное время (и игры, и интернет). Мой ноут тоже такой :), недавно только закупили специализированный ноутбук SIMATIC Field PG, на котором соблюдаем «карантин». Впрочем, мне пока на опасных производствах не доводилось работать :)
3. Червь загружает вредоносный код в PLC в момент его программирования с инженерной станции путём перехвата трафика между станцией и PLC (заодно червь перехватывает обратный трафик и скрывает свой код). Таким образом, все пароли на проект идут лесом.
4. Если с незаражённой станции попытаться глянуть зараженный червем блок в PLC, то Step действительно ругнётся, что блоки в локальном проекте и в PLC не совпадают. Вот только очень редко другой инженер при этом откроет блок из «онлайна» (из PLC), чтобы посмотреть чего там не то, а скорее пнёт другого инженера (с заражённым ноутом), чтобы тот внёс нужные изменения или слил свежую версию проекта (заражённую червем ;). Да и вообще, как правило, при работе над сложной системой несколько разработчиков делают каждый свой кусок, а блоки, отвечающие за последовательность работы программы в целом пишет более опытный мега-инженер, настолько уверовавший в своё всемогущество, что позволил себе днём ранее почитать на своём ноуте свежее ТЗ, которое какой-то неизвестный местный притащил ему на флешке.
дисклеймер: всё вышеописанное является вымыслом, все совпадения с реальностью случайны и не имели место в действительности :)
вот, честно признаюсь, у меня на рабочем ноуте свалка проектов контроллеров (вплоть до нескольких 400й серии) со многих предприятий. атомных станций, правда, нет :)
не исключено, что некий атакуемый проект (не обязательно бушеровский) был украден из ноутбука (или вместе с ноутбуком) одного из разработчиков аналогичной моей степени раздолбайства :)
Я просто по работе слегка знаком с сименсовским промышленным оборудованием (сертификаты Step7 и WinCC, а также статус Siemens Solution Partner :)