?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Радости утра понедельника. Контрольная инженерия [30 Mar 2009|12:24pm]
Про компетентность и легитимность, выстраиваемых на неразрешимых задачах -- http://david-gor.livejournal.com/82087.html. Я очень рекомендую читать этот пост, не обращая внимания на то, что это про "влияние на власть". Поскольку любые (даже технические) задачи, ежели они большие, сводятся очень часто к задачам влияния, то это верно и для производства.

david_gor предлагает следующий рецепт: получать компетентность, решая неразрешимые задачи (ибо при решении таких задач компетентность растет взрывным образом). По достижении компетентности в какой-то области (т.е. признания всеми того, что других специалистов такого класса в этой области нет) нужно сдвигаться на другие области -- легитимность приходит тогда, когда суперкомпетентность проявляется в разных областях и возникает понимание, что такое может произойти с потенциально любой областью: люди начинают верить не тебе и/или организации, как узким специалистам в чем-то конкретном, а тебе и/или организации как таковым, honoris causa.
* * *
Еще один гигантский дисплей -- на этот раз из бегающих овцепикселей: http://www.youtube.com/watch?v=D2FX9rviEhw (via _lothar_), но я так и не понял, как именно этими овцепикселями так точно управляют.
* * *
Ежели SysML -- это не так хорошо (в плане масштабируемости), то что хорошо?
* * *
Очередной спам от проходимцев -- "полная проходимость писем через все спам фильтры".
* * *
Какие чудные дискуссии у меня были в эти выходные -- и в ЖЖ, и по переписке...
* * *
Про "контроль" и "управление" в переводе слова control можно писать поэмы. Инженеры, когда говорят control, сказать обычно хотят "наша АСУ ТП контролирует ваш реактор, никуда он не денется, не рыпнется и не сбежит", а не "наша АСУ ТП управляет вашим реактором, и уговаривает его путем демонстрации своего лидерства". Ежели речь идет не о реакторе, то слово control тоже обсуждает обычно отсутствие возможности побега и уклонения (и даже не кибернетическую модель обратной связи с "мониторингом и реагированием").

Переводить control как "управление", а management как "менеджмент" или даже "руководство" неправильно. Вот что говорит maksimotstavnov (из частного письма):
...делать этого все равно не нужно, поскольку как только от мертвых документов дело дойдет до живых текстов, передавать придется каждый член ряда "to manage --- management --- managerial ...".

У нас уже есть транскрибированный ИСО9000, там и "менеджмент", там и "процессный" и все прочее присутствует, осталось только найти задницу, в которую это все засунуть.

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

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

Терминолог с ужасом обнаруживает, что при осмысленной речи меняются не только смыслы, но и значения.)
Добавлю от себя, что management меньше всего похож на руководство. Это control похож на руководство в абсолютно командно-принудительном стиле. В наших текстах будет везде смысл "взять территорию под контроль" (а не "поставить территорию под управление"), "я контролирую твоих людей" (а не "я управляю твоими людьми"), "я держу этого удава под контролем" (а не "я управляю этим удавом").

Слово control в английском языке имеет два ударения, и от этого меняется смысл -- мы говорим тут только об одном из этих значений. Я третьего дня на конференции долго думал на эту тему, глядючи на презентации людей из АСУ ТП. У них есть ведь слово "контрОллер" (программно-аппаратный), а не "управлятор", которое не дает безболезненно соскочить на "управление". В обыденной речи мы не говорим, что контроллер "контролирует" устройство. В некоторых областях техники закрепилось "управляющее устройство" или "устройство управления". А в специальной речи тут же перемешиваются фразы с "контролем" и "управлением", они их разделяют всяко. Кстати, в управлении (management) тоже есть controlling. Опять вставка от maksimotstavnov:
англофоны тоже различают "to manage" и "to control" совсем не так четко, как об этом пишут в словарях. У них есть еще всякие клевые "to drive", "to handle". В английском "controller" может означать и должность: это часто "диспетчер", "оператор", "регулировщик", и очень редко "контролёр"
Я лично буду привыкать: control -- контроль, "взять за шкирку". Management -- от manage, "уладить". Поэтому диспетчер/оператор/регулировщик контролирует=командует, а менеджер "делает предложения, от которых трудно отказаться".

Про "ложных друзей переводчиков" -- это к Шекспиру и прочей художественной (а не процессной) литературе. Жизнь меняется, язык меняется, жизнь меняется быстро, язык меняется быстро.

Само словосочетание control engineering я буду переводить контрольная инженерия (даже не "инженерия контроля", так же как "программная инженерия", а не инженерия программ) и использовать в словосочетании системная, программная и контрольная инженерия. Потихоньку привыкнется. Уж всяко лучше, чем управляющая инженерия.

Но привыкается трудно, согласен. Буду тешить себя тем, что затем никто не возьмется "контролировать персонал", когда речь пойдет не только об интеграции в одно целое системной, программной и контрольной инженерии, но и человеко-системной интеграции (HSI).
7 comments|post comment

Конвергенция: моделецентрическая программная, системная и контрольная инженерия [30 Mar 2009|12:26pm]
Восход киберфизических систем -- в которых сам черт не разберет, что делается "механически", а что делается при помощи компьютера:

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

А вот будущие тренды:
-- технологии контроля многих транспортных средств для управления трафиком, направления к местам назначения и безопасности
-- автомобильные сети
-- поглощающие энергию "умные материалы" для защиты от столкновений (вплоть до кооперативных "зон аварии")
-- альтернативные топливные технологии, "умная поверхность", включающая солнечные батареи, энергосбережение
-- интегрированная работа "поездов" из машин, "умные шины", активные аэродинамические поверхности
-- безопасность (safety and security), удостоверение личности, правопринуждение
-- замена механизческих связей "проводами"

Ну, и компьютеры в уменьшении времени выхода на рынок, плюс уменьшении цены (автомобиль Форда стоил $500, вчера официально прошел запуск Tata Nano -- этот индийский автомобиль стоит $2000).

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

Киберфизические системы очень трудно создать: это пересечение трех совершенно разных управленческих дисциплин с разными традициями, языками, стандартами -- системы (железные), программы для ЭВМ, контроль (АСУ ТП). Нет общих стандартов, нет общих инструментов, нет общего образования. Верификация и валидация киберфизических систем -- это кошмар, потому как целостность их непонятно как проверять, никто не держит общую картинку.

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

Для системной инженерии моделецентричный дизайн уже де-факто практика жизни.
Для контрольной инженерии моделецентричность широко распространена в связи с появлением популярных инструментов типа MathWorks Simulink/StateFlow.
Для программной инженерии моделецентричность растет через популяризацию МDA от OMG и растущему изобилию инструментальных средств моделирования софта.

Задача в том, чтобы заставить все три вида моделей работать вместе, что невероятно трудно.

Это я потихоньку пересматриваю и пересказываю презентацию Janos Sztipanovits "Convergence: Model-Based Software, Systems And Control Engineering" (http://www.infoq.com/presentations/Model-Based-Design-Janos-Sztipanovits), это только первые 19 минут.
10 comments|post comment

Родственники PraxOS [30 Mar 2009|10:28pm]
vit_r помог найти софтверных родственников PraxOS: http://www.opfro.org/. Делает это http://www.open.org.au/, история которого заканчивается записью от сентября 2006г., в которой поминается гармонизация с ISO 24774 (мы в PraxOS выпустим версию 0.9 гармонизированного перевода этого стандарта на русский как раз на этой неделе -- и рассмотрим ее на заседании группы INCOSE).

Интересно, что аффилированные с ними фирмы тоже оказались идейно близки. Так, мы софт PraxOS поначалу думали выпустить в форме такого специального issue tracker, который способен поддерживать еще и проектное управление -- так есть использующая OPEN (Object-oriented Process, Environment and Notation) и их репозиторий OFP (OPEN Process Framework) фирмочка http://www.etrack.com.au (выключите звук! их сайт громко щелкает!), похоже, выпустила что-то очень похожее на первоначальную задумку. Не удивлюсь, ежели через год-другой окажется, что там появятся и упоминания ISO 15926.

Нужно покопаться.
2 comments|post comment

navigation
[ viewing | March 30th, 2009 ]
[ go | previous day|next day ]