M.C.Escher 'Drawing hands'

M.C. Escher 'Drawing hands' 

'Имею желание купить дом, но не имею возможности.
Имею возможность купить козу, но не имею желания.
Так выпьем за то, чтобы наши желания
Совпадали с нашими возможностями!'

Тост из кинофильма "Кавказская пленница"

Возможно читателю будет интересно ознакомиться с проектом The Industrial Ontologies Foundry Proof-of-Concept, который я обнаружил в процессе работы над этой статьей. Он предназначен для поддержки компьютеризации производства соответственно современному тренду Industry 4.0. Предлагаемая Онтология Желаний предполагает включение в свой состав подобных подходов, но преследует более широкие цели:

Оперативное определение тенденций

Например, участившееся желание Нормализовать Уровень:

  • "Жизнеобеспечения / Воды" в контексте человека может означать раннюю стадию диабета, а в контексте жилого дома - прорыв трубы централизованного водоснабжения.
  • "Жизнеобеспечения / Энергии" в контексте человека может означать "необъяснимое" пробуждение аппетита у большинства населения страны, а в контексте автомобиля - необходимость заменить свечи зажигания или найти заправку, где не разбавляют бензин.
  • "Информированности / Email" в контексте человека может означать начало стресса или психологической зависимости от интернета, а в контексте метеорологической службы - выход из строя GSM-модуля удаленного датчика температуры и т.д.

Обратим внимание на то, что в первом случае количество жидкости в организме человека может быть вполне нормальным. Подобным образом, желание электронного устройства "Нормализовать Уровень Комфорта / Температуры" может означать необходимость перенести его в тень, а не выход из строя вентилятора охлаждения. Из приведенных примеров следует, что стандартный метод выявления проблемы посредством опроса состояния датчиков (воды, энергии, температуры) не всегда достаточен. С другой стороны, предлагаемый подход реагирования на желания сущностей стандартизирует, упрощает и удешевляет решение задачи определения тенденции.

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

Приведенный выше тост частично характеризует базовую идею предлагаемой онтологии в виде пути к исполнению Желания через единство и взаимодействие противоположностей. Я применил слово "взаимодействие" вместо Гегелевского, общепринятого в данном контексте слова "борьба", к которому больше подходит иллюстрация в виде символа Инь-Ян. Демонстрируя крайнюю степень противоположности посредством контраста цветов - черный Инь и белый Ян, этот символ заведомо предполагает третейского судью, который назначил им роли хорошего-плохого, начальника-подчиненного и т.д. Однако, основывать описание сущностей на базе жестко определенных суждений о таксономии, назначении, полезности или вреде свойств, может, в общем случае, привести к ошибкам и логическому тупику. Ушибленный мизинец может временно стать главней всех остальных органов, мыслей и желаний...

Упрощение и стандартизация компьютерных программ

Душа содрогается когда читаешь расшифровку моментов времени 05:41:46 и 05:43:20 отчаянной борьбы пилотов с холодной бездушной автоматикой. Каждая строка NATOPS написана кровью и не допускает разночтений. Этот стандарт содержит устоявшуюся, наработанную десятилетиями общепринятую терминологию, и представляет собой детальное руководство к действию экипажа в любой внештатной ситуации. По-сути это не четко формализованный описатель работы компьютерной программы, который нельзя измененять, но можно дополнять для поддержки летательных аппаратов со специфичной аэродинамикой. Но означает ли это, что в таком случае должна выпускаться новая версия программного обеспечения верхнего уровня, которая может по-своему интерпретировать ситуацию и запрещать пилоту корректировку своих действий? Не проще ли и надежней следовать известному принципу Э. Дейкстры - фиксированный алгоритм работы программы при изменяемых данных?

В конце лекции Лесли Ламберта "Размышляя над кодом" один из зрителей утвержает, что 95% программистов так не пишут программы. Я отношусь к оставшимся 5% и подхожу к программированию даже простейших MCU с точки зрения спецификаций, хотя никогда не применял TLA+. В этом случае код получается минимального размера, относительно постоянен для широкого спектра приложений и сводится к обработке спецификаций. Считаю, что такой подход скоро вытеснит остальные методы программирования, поэтому, например, поставил задачу, чтобы отлаженный код программы интернет-магазина не требовал изменений в будущем, при любой сложности описателя продукта.

Защита информации

Находясь, по меткому выражению Роксаны Медоуз в "состоянии каннибалов в Кадиллаке", мы широким шагом движемся в направлении к IoT. При этом, на сегодняшний день нет активной по-умолчанию 100% защиты не только автоматического устройства, но и обычного пользователя от компроментации и/или психологического воздействия путем:

  • взлома электронной почты или аккаунта в социальных сетях с последующей подменой сообщений
  • спуффинга URL или DNS для перенаправления пользователя на ложные сетевые ресурсы
  • создания ложных мобильных GSM-станций, которые можно использовать не только для подслушивания, но и динамичного пранкинга
  • применения визуальной и акустической стеганографии. Нет также стандартного механизма защиты от стеганографии в шрифтах и даже в обычных текстовых файлах, "почему-то" изобилующих грамматическими ошибками.

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

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

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

В общем случае, я не вижу пока возможности защиты рядового пользователя от многовекторного жесткого шпионажа и психологического воздействия. Надеюсь на квантовые компьютеры, в связи с их природным дуализмом, хотя вопрос защиты средств ручного ввода информации все равно остается актуальным. Тем не менее, предлагаемая Онтология Желаний имеет целью стандартизировать способы защиты сущностей при их взаимодействии на всех этапах и уровнях жизни (от человека до простейшего MCU). Помимо других, в ее основу будут заложены принципы IBM Identity Mixer.

Конкретизация обязанностей и исключение посредников

'Гарант может на основе принципа «отчуждения разработчика от своего изделия» гарантировать Заказчику, что всегда найдет команду сопровождения по данному проекту, например, в случае, если Исполнитель откажется от сопровождения своего же внедрения или от внедрения своего же программного изделия.'

"Социальный труд и открытое проектирование. Введение"

В этой статье автор предлагает к рассмотрению концепцию "ИТ-теплицы нового типа социального предпринимательства", и вводит Посредника в список производителей продукта, как обязательное звено между Заказчиком и Исполнителем. Идея отчуждения Исполнителя от средств производства и результатов своего труда не нова. Достигать этого можно разными способами, и один современный пример я уже приводил.

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

Онтология Желаний предназначена для поддержки проекта "Общее дело" (далее CB) и имеет целью создание прямых связей между Заказчиком и Исполнителем. При этом, сообщество является одновременно Заказчиком, Исполнителем, Владельцем, Защитником Прав и Хранителем документации на изготовление любого продукта, созданного его членами. Сторонние организации могут лишь попросить CB внести разработку в свои планы и оставить за ними право поощрения за идею и приоритетного получения готового продукта.

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

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

Проект Устава CB должен быть опубликован для обсуждения и этому будет посвящена отдельная статья.

Боб в Лас-Вегасе

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

Мы помним, что у Боба появилась новая подружка. Теперь он предложил ей провести уикенд в Лас-Вегасе, но в последний момент неожиданные дела задержали его и она оказалась там на день раньше. Хотя возраст уже не позволяет Бобу лазить в окна к любимым по водосточным трубам, он сохранил юношескую сентиментальность и любит оригинальность. В аэропорту Лас-Вегаса недавно появился сервис доставки посылок посредством дронов в любую точку города за 15 минут. Причмокивая губами он написал любимой пламенную записку, вложил в пакет букетик фиалок и пошел выбирать автомобиль на прокат. Уже через 10 минут дрон был на крыше отеля и сбросил посылку в открытый ящик робота-носильщика. Тот обладал потрясающим интеллектом, умел читать текст, написанный вручную, мог поднять груз весом до 100 кг и знал все закоулки отеля от крыши до подвала. Однако, чтобы поддерживать все упомянутые возможности ему требовалось много энергии и как раз сейчас наступило время подзарядки аккумулятора. Это заняло всего 20 минут, но когда он подъехал к дверям лифта, Боб уже парковал автомобиль на стоянке отеля.

'CoBot способен перемещаться на нескольких этажах и между ними. Чтобы перемещаться между этажами, CoBot активно просит человека [Rosenthal and Veloso, 2012] нажимать кнопки лифта.'
Localization and Navigation of the CoBots Over Long-term Deployments (part 6. Navigation)

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

Роботу надо было спуститься всего на один этаж, но за 10 минут никто не подошел к лифту. Его не интересовали чаевые за скорость доставки и он ждал случайного прохожего, сохраняя "железное" спокойстие. А в это время, старина Боб стоял в дверном проеме номера и растерянно повторял подружке в объятиях незнакомца: "Я так и знал! Ты не любишь фиалки ..." 

Понятно, что прежде чем увлечься очередной молодой красавицей Бобу следовало заглянуть в свой паспорт на предмет даты рождения. И все же, как бы вы оформили взаимодействие IT-сущностей доставки письма, чтобы легкомысленный Боб окончательно не потерял способность улыбаться?