Промышленное программирование *

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

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


DDJ: Вы программируете компьютеры, которые работают на поверхности другой планеты. Вот это необычно!

GR: Это необычно и для меня, могу вас заверить. Это такой микромир, где все сосредоточены на том, чтобы все задачи следующего дня были выполнены в соответствии с планом.

Вы идете домой в 3 утра, все еще в напряжении от просмотра возвращающейся информации и бессонной ночи. Ваши жена и дети уже спят, вам же точно не уснуть, а в 8 утра уже надо быть на работе. Поэтому вы включаете CNN и смотрите на свое улыбающееся лицо в контрольном центре и смотрите на те же изображения, которые вы просматривали 12 часов назад. Очень странное ощущение.

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

В 1971 году СССР доставили на Марс первые в мире планетоходы «на лыжах», которые должны были щупом (динамический пенетрометр и гамма-лучевой плотномер) ткнуть поверхность, и сказать — Марс твердый или жидкий пыльный. Первый аппарат разбился 27 ноября, второй совершил мягкую посадку 2 декабря, но марсоходик не смог выбраться из «скорлупы» посадочного модуля, поэтому попытку не засчитали.

Прошло 25 лет.
4 июля 1997 года на Марс прилетел американский аппарат и привез «пришельца» с первым багом.


Кадр из к/ф «Марсианин». Главный герой держит в руках марсоход Sojourner

Проект был под угрозой, но мощные инструменты отладки операционной системы и отличная работа программистов на Земле (парни, что надо) позволили в кратчайшие сроки все быстренько исправить.

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

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

Однажды, появилась необходимость использования в нашем устройстве мультиплексного канала обмена информацией (МКИО), он же ГОСТ Р 52070-2003, он же MIL-STD-1553В. Первоначальный результат поисков несколько удивил: типовые решения выдаваемые поисковой системой, как правило, основывались на использовании ПЛИС. Поскольку решать проблему нужно было быстро, появилась мысль сделать конвертер протокола из MIL-STD-1553 в MODBUS RTU. При этом постараться использовать достаточно недорогие технические решения и микроконтроллер из семейства STM32.



На фото из Википедии: F16, на котором впервые был использована шина MIL-STD-1553В. Наши устройства не летают :), поэтому каких либо ограничений по применению элементной базы нет. Просто у Заказчика приборная сеть построена на основе этой шины. Первая часть статьи описывает прием и передачу по шине МКИО, вторая часть будет про конвертер в MODBUS.

Задача: Компания (далее Компания) разрабатывает и выпускает некоторый продукт (далее Продукт). Необходимо создать программное обеспечение для проверки Продукта на сборочной линии (далее Линия) некоторой сторонней или принадлежащей компании фабрике (далее Завод).

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

Цель: Грамотно сгладить ошибки разработки тестового ПО для фабрики, допускаемые в процессе жизненного цикла Продукта.

Примечание: под Продуктом понимается некоторое устройство или его часть, обладающее внутренней логикой, SW / FW / Функционал которого требуется проверить. Пример: сотовый телефон, контроллер, программируемые устройства, материнская плата.

Предыстория

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

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

И тут появляется .jdf и CIP4

И вот в 1999 на помощь печатной индустрии пришёл консорциум CIP4, чьё название расшифровывается как “Cooperation for the Integration of PrePress, Press, PostPress and Process”.

В данной статье проведена систематизация требований к информационной безопасности (ИБ) АСУ ТП. Требования выбраны из доступных на настоящий момент стандартов, в первую очередь, из NIST SP 800-82 «Guide to Industrial Control Systems (ICS) Security» и разрабатываемой новой редакции серии ISA/IEC 62443 «Security for Industrial Automation and Control Systems».

АСУ ТП взаимодействуют с объектами физического мира и обеспечивают защиту от аварий и катастроф. В англоязычной литературе АСУ ТП называют Industrial Control Systems (ICS) или Industrial Automation and Control Systems (IACS). В мире IT технологий их можно сравнить с Дон Кихотом, который остался верен простым, но не очень модным принципам в уже давно изменившемся мире.

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

Похожие проблемы следует решать и для других кибер-физических систем, включая IoT и встроенные управляющие системы.

Для кого
— Для тех кто использует OpenSCADA, но не может реализовать больше чем решения «из коробки»
— Для тех кто ищет СКАДу для себя, но так и не может определится
— Для тех кто забросил этот проект, так и не разобравшись как он работает

Зачем
— Данное решение позволяет считывать показания счетчиков меркурий 230 и меркурий 200 без каких либо лимитов
— Это бесплатно

Проекту openscada (oscada.org) уделяют не заслужено мало внимания, о нем написана всего одна статья на хабре. Большинство инженеров боятся трогать и трехметровой палкой этот продукт, черт его знает какой этот ваш линукс. Разрабатывает его уже не первый десяток лет фактически один человек, Роман Савоченко.

TDD не работает.

Правда? Странно. У меня всегда работал хорошо.

А вот новое исследование говорит об обратном.

Новое исследование?

Да, глубокое исследование, повторившее шаги другого исследования, проведенного несколько лет назад. Оба показали, что TDD не работает. Новое исследование проходило в нескольких местах, использовало слепой анализ. Выглядит убедительно.

Авторы считают его убедительным?

Авторы рекомендуют проводить новые исследования. Но они скорее всего просто скромничают. Результаты довольно убедительные.

Какие результаты?

Среди идеально-зеленых швейцарских лугов, по соседству с коровником, стоит современное минималистичное здание с панорамными окнами. Здесь расположены главный офис и основные производственные мощности швейцарской компании IST-AG.

Большую часть продукции, которую выпускает IST-AG, составляют тонкопленочные датчики температуры, они же термосопротивления (RTD). Из статьи "Термосопротивления: теория" можно узнать что это такое и как оно работает.



Сегодня расскажу об основных этапах производственного процесса. Как и на производстве полупроводников, всё начинается с керамической подложки..

Недавно мне повезло побывать на производстве датчиков температуры, а точнее на швейцарском предприятии IST-AG, где делают платиновые и никелевые термосопротивления (RTD).

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



В первой статье разбираемся с теоретической базой. Не слишком увлекательно, но весьма полезно.

Обычно люди идут в магазин автозвука и покупают компоненты. Я же сначала спаял цифровой аудиопроцессор, а компоненты поставил какие есть.

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

В этот раз мы хотели бы рассказать о несколько неординарном способе защиты электронных инженерных данных от несанкционированного коммерческого использования сторонними лицами, или коротко — плагиата.

11 февраля 1991 года Patriot Project Office получил израильские данные о дефекте в ракетной системе Patriot. Они нашли, что если система работает 8 часов, она начинает мазать на 20%. Они прикинули, что после 20 часов работы система начинает промахиваться настолько, что перестанет быть способной захватывать, отслеживать и поражать баллистические ракеты. Американские военные не приняли во внимание всю важность открытия, заявив, что система предназначена для портативных и краткосрочных защитных операций и что никто никогда не будет использовать систему больше 8 часов.

16 февраля был выпущен Bug Fix, но чтобы его внедрить во все единицы боевой техники, требовалось время, ибо война.

21 февраля военные выпускают указание, что система не должна работать «долго». Военные не уточнили сколько длится «долго».

25 февраля в Дахране (Саудовская Аравия) в казарму в гости к американцам прилетела баллистичекая ракета "керосинка" (она же Р-17, она же Scud). 28 убито 96 ранено, потому что ЗРК «Патриот» промахнулся из-за программной ошибки.

26 февраля Bug Fix был доставлен в Дахран.

Работать в проекте без ошибок — мечта любого ИТ-шника. Достижимо ли это в реальности? Этот вопрос является одновременно и простым и сложным, потому что, чтобы избежать ошибок, надо с одной стороны иметь строго выверенную цепочку, начиная от формирования общих требований, до детальной реализации. С другой стороны, в сферу ИТ вливается поток специалистов, которые слабо представляют, как можно доказать отсутствие ошибок в программе или выстроить структуру, которая сокращает возможности ошибок, прежде всего логических, которые носят принципиальный характер.

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

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

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

Эта статья заканчивает цикл публикаций о разработке измерительного устройства в онлайн IDE mbed от компании ARM.

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

Предыдущие статьи:

• [Часть 1] Обзор использованных программных и аппаратных решений.
• [Часть 2] Начало работы с графическим контроллером FT800. Использование готовых mbed-библиотек для периферийных устройств.
• [Часть 3] Подключение датчика HYT-271. Создание и публикация в mbed собственной библиотеки для периферийных устройств.
• [Часть 4] Разработка приложения: Структура программы, работа с сенсорным экраном.
• [Часть 5] Разработка приложения: Вывод изображений на дисплей, проблемы русификации.

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

Кстати, одновременно с публикацией этой расшифровки начинается вторая встреча из серии, посвящённой технологиям Яндекса. Сегодняшнее мероприятие — уже не про поиск, а про инфраструктуру. Вот ссылка на трансляцию.


Ну а под катом — лекция Петра Попова и часть слайдов.

Безопасности на хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда.

Данная статья продолжает серию публикаций на тему функциональной безопасности.

В данной статье достаточно абстрактные требования к управлению функциональной безопасностью интерпретированы для внедрения в рабочие процессы. Эта информация проверена и отшлифована на практике нескольких проектов по сертификации.
Процессная инженерия – скучно это или нет? Именно процессы позволяют масштабировать IT-бизнес. Мне лично приходилось наблюдать, как внедрение процессов в разработку приводило к серьезному профессиональному росту, как исполнителей, так и всей компании. И наоборот, «затыки» и так называемая «нецелесообразность» внедрения хорошо структурированных процессов свидетельствовали о незрелости и других серьезных проблемах.
Итак…