M.C.Escher 'Drawing hands'

M.C. Escher 'Drawing hands' 

'Маю бажання купити будинок, але не маю можливості.
Маю можливість купити козу, але не маю бажання.
Так вип'ємо за те, щоб наші бажання
Збігалися з нашими можливостями!'

Тост з кінофільму "Кавказька полонянка"

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

Оперативне визначення тенденцій

Наприклад, участившееся бажання Нормалізувати Рівень:

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

Звернемо увагу на те, що в першому випадку кількість рідини в організмі людини може бути цілком нормальним. Подібним чином, бажання електронного пристрою "Нормалізувати Рівень Комфорту / Температури" може означати необхідність перенести його в тінь, а не вихід з ладу вентилятора охолодження. З наведених прикладів випливає, що стандартний метод виявлення проблеми за допомогою опитування стану датчиків (води, енергії, температури) не завжди достатній. З іншого боку, пропонований підхід реагування на бажання сутностей стандартизує, спрощує і здешевлює рішення задачі визначення тенденції.

Онтологія Бажань звичайно ж повинна спиратися на QUDT і інші відомі доменно-незалежні онтології. Однак, на мій погляд, безпосереднє застосування доменно-залежних онтологій в даному контексті призведе до невиправданого ускладнення кінцевих описателей. Адже нам, як мінімум, має бути розширити їх в плані підтримки валідації і обмеження доступу до даних, що в кінцевому підсумку може відштовхнути звичайного користувача своєї заплутаністю.

Наведений вище тост частково характеризує базову ідею пропонованої онтології у вигляді шляху до виконання Бажання через єдність і взаємодію протилежностей. Я застосував слово "взаємодія" замість гегелівського, загальноприйнятого в даному контексті слова "боротьба", до якого більше підходить ілюстрація у вигляді символу Інь-Ян. Демонструючи крайню ступінь протилежності за допомогою контрасту кольорів - чорний Інь і білий Ян, цей символ свідомо припускає третейського суддю, який призначив їм ролі хорошого-поганого, начальника-підлеглого і т.д. Однак, засновувати опис сутностей на базі жорстко певних суджень про таксономії, призначення, корисності або шкоду властивостей, може, в загальному випадку, привести до помилок і логічного глухого кута. Забитiй мізинець може тимчасово стати головніше всіх інших органів, думок і бажань ...

Спрощення та стандартизація комп'ютерних програм

Душа здригається коли читаєш розшифровку моментів часу 5:41:46 і 5:43:20 відчайдушної боротьби пілотів з холодною бездушною автоматикою. Кожен рядок NATOPS написан кров'ю і не допускає різночитань. Цей стандарт містить усталену, напрацьовану десятиліттями загальноприйняту термінологію, і являє собою детальне руководство до дії екіпажу в будь-якої позаштатної ситуації. По-суті це не чітко формалізований описатель роботи комп'ютерної програми, який не можна змiнювати, але можна доповнювати для підтримки літальних апаратів зі специфічною аеродинамікою. Але чи означає це, що в такому випадку повинна випускатися нова версія програмного забезпечення верхнього рівня, яка може по-своєму інтерпретувати ситуацію і забороняти пілотові коригування своїх дій? Чи не простіше і надійніше слідувати відомим принципам Е. Дейкстри - фіксований алгоритм роботи програми при змінюваних даних?

В кінці лекції Леслі Ламберта "Розмірковуючи над кодом" один з глядачів затверджуе що 95% програмістів так не пишуть програми. Я вiдношуся до решти 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 та Veloso, 2012] натиснути на кнопки ліфта.'
Localization and Navigation of the CoBots Over Long-term Deployments (part 6. Navigation)

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

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

Зрозуміло, що перш ніж захопитися черговий молодою красунею Бобу слід заглянути в свій паспорт на предмет дати народження. І все ж, як би ви оформили взаємодію IT-сутностей доставки листа, щоб легковажний Боб остаточно не втратив здатність посміхатися?