?

Log in

No account? Create an account

Previous Entry Share Flag Next Entry
Пофантазируем: что будет в .15926 Editor дальше?
2019
ailev wrote in dot15926
На следующей неделе должна выйти версия 1.2 с поддержкой пользовательских паттернов.
Весной выйдет версия 1.3 с поддержкой управления конфигурацией и изменениями данных ISO 15926.

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

1. Редактор/генератор графических диаграмм (можно обсуждать, каких именно: вариантов тут более чем множество).

2. Консоль естественного языка с теми же полномочиями, что и питон-консоль. Но вместо питонных code snippets пишутся запросы на естественном языке (а в случае непонимания, что нужно делать, поддержится диалог). Сразу оговорюсь: язык только английский!

3. Прикручиваем веб-фреймворк, а из софтинки делаем веб-сервер. Вариант: не прикручиваем веб-фреймворк, а просто используем толстый клиент (т.е. бьём софтинку на серверную и клиентскую половинки). Мучаемся с поддержкой многопользовательской работы и онлайном.

4. Делаем честную поддержку MOF (такую же честную, как поддержку OWL/RDF). Читаем-пишем .cmof с метамоделями, .xmi с моделями. Дружба-жвачка с OMG.

5. Разгоняем движок на пару порядков в плане скорости работы логического вывода. Добавляем разворачивалку темплейтов, явную поддержку business rules.

6. Интегрируем системы научного питон-компьютинга по образу и подобию Simantics. Все big data нуждаются в том, чтобы быть подробно описанными, все deep learning в гости к нам.

7. Верим, что появятся быстрые SPARQL-сервера и пытаемся сделать компилятор запросов для чужих SPARQL-endpoint (в надежде, что они будут выполняться не вечность).

8. Портируемся на макось, 64-битную винду, линукс и андроид. Рапортуем о "доступности на всех платформах" (не спрашивайте, кому рапортуем. Мы ведь фантазируем, да?).

Ещё идеи?

UPDATE:
1. Понимаем, что можно пойти в сторону simantics: пытаемся сделать что-то своё из этой серии, прикручивая какие-нибудь фреймворки для моделирования.
2. А есть ещё очень похожая на simantics область: роботика, где довольно много уже XML "языков", куча фреймворков, активно используется Питон и наверняка есть нужда в хоть каком-то интеграционном решении.

3. Очень важно для "классических онтологов" иметь встроенные метрики (типа "насколько вы отошли от таксономии и у вас представлены и другие отношения"), верификаторы, поддержка хитрых методологий по слиянию онтологий, характеризации (типа OntoClean и т.д.). Вот этот "сервис в ассортименте" и реализовать. Обсуждается это всё в изобилии сегодня на Ontolog Summit 2013 (там тема этого года -- оценка онтологий, материала на эту тему хоть отбавляй).


  • 1
1) Портируемость на 64-битную 8-винду;
2) RDL для роботов и М2М-систем;
3) Сделать .15926 Компилятор (генератор) для промышленных систем;
4) Замахнутся на чип-компоненты (наверно, пока мейдн Китай на 40 или 22 (14) нм технологических нормах);
5) Как итог, сделать полностью 15926-робота.

п.с. возможно хотелки выходят за уровень .15926 Editor)
Готов поучаствовать в реализации.

Пытаюсь понять, что вы написали, но не очень получается. Попробую так: вы говорите, что нужно сделать мультиагентскую систему над базой знаний в ISO 15926. Ибо у нас тупой Питон и семантическая сетка, без агентов. А нужно с агентами (работ по онтологиям и агентам много разных -- вот, например, один из активистов, http://www.jamesodell.com/publications.html, хотя он и не про роботов).

Портируемость на 64-битную 8 винду пока не понял, для чего, и как связана с роботами (ибо роботы представлены были "как итог", я понял, что написан какой-то последовательный план, а не отдельные пункты).

Про m2m системы и RDL я хорошо понимаю, но это больше похоже сейчас на разработку расширения (тем более, что питон легко засунуть внутрь любого робота, тамошние компьютеры вполне сильны для этого). Правильно ли я понимаю, что вы предлагаете ISO 15926 в качестве формата обмена данными между внешними системами и роботом? Интересная мысль: это может заменить десятки и сотни разных хитрых форматов данных, обмен которыми идёт по самым разным интерфейсам -- диагностика, результаты, команды, апдейты софта, там ведь примерно такой же зоопарк интерфейсов и стандартов, как и в тех же САПР. А тут мы говорим, что внутри робота есть интерфейс ISO 15926, и не нужно больше думать о формате обмена информацией и разных стандартах, а просто обмениваться этой информацией. Для простых роботов это будет очень тяжело, а вот для сложных интеллектуальных может оказаться самым нормальным решением (ибо ни в один стандарт нельзя будет упихнуть то, что будет приходить в голову людям).

Только тут нужно разобраться, где ISO 15926 outside, а где ISO 15926 inside.

Итого: лёгкий путь тут начинать с расширений для тех или иных наборов данных, которые нужны роботам. То есть нужно взять любой стандарт поперспективней для роботов, и отмэппить его на ISO 15926. Потом взять другой стандарт, и тоже отмэппить. А потом объявить, что реализован обмен данными между роботами разных стандартов, причём методом, который позволяет добавлять этих роботов!

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

Если у вас есть доступ к разным роботам, то вполне можно приступать к реализации :-)

про 8 винду - вопрос снят.

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

Реализацию хотелось бы начать с теории и плавно перейти к железу.

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

Хотелось бы решить проблему создания внутренней iRING архитектуры .15926 управления компонентами робота, с возможностью "горячей" замены без переписывания программ управления

Тогда вам нужно разработать кейс такой "горячей замены", сформулировать поточнее, в чём там "проблема", которую ISO 15926 inside будет решать лучше, чем "просто структуры данных языка программирования, как обычно".

Вот поглядите: есть множество открытого софта для роботов -- и они как-то пытаются друг с другом дружить (http://www.ros.org/wiki/ROS/Introduction). Собственно, ISO 15926 можно использовать традиционным образом -- для того, чтобы иметь возможно коммуникации роботов с этими фреймворками (например, брать информацию с датчиков одного робота и использовать в движениях другого робота, даже если они сделаны с использованием разных робот-фреймворков aka операционных систем для роботов).

Другое дело, что ISO 15926 не имеет сразу "из коробки" справочных данных для этого, но эти справочные данные вполне можно доразработать.

1)есть ли ограничения по реализации робот-фреймворка реального времени? есть опасения, что не будут успевать обрабатываться многочисленные датчики.Особенно если будет попытка "взлететь".
2)интересно рассмотреть справочные данные для видеокамеры, гидропривода, сервоприводов с энкодером, и сенсоров положения исполнительных механизмов. подскажите если можно учебный пример разработки справочных данных для указанных типов.

Я, вроде, ссылку начальную вам привёл? Вы уж сами как-то эти вопросы поизучайте (обратите внимание, в этой сфере довольно много XML форматов -- верный признак того, что необходимо универсальное представление данных. Вот и начните их все потихоньку мэппить, сделайте расширения по их чтению-записи, заодно и разберётесь с ответами на ваши вопросы).

Роботика сама по себе очень сложна, а тут ещё ISO 15926 (справочными данными для роботики, насколько я знаю, в ISO 15926 никто не занимался). Нужно понимать, на какие трудозатраты вы идёте, ввязываясь в эти две предметные области. Ну, и зачем вы это делаете, чего хотите достичь.

достичь, как вы уже указали - некоего интеграционного решения или даже решений, для разных классов роботов

Тогда у вас должен быть юскейс, и как минимум пара роботов для экспериментов ;-)

Идей с ходу нет, поэтому позволю себе проголосовать и прокомментировать.

Мне бы больше всего пригодились: 1 и 3.

По поводу xmi могу сказать, что там ждут мучения, похожие на те, что у вас уже были с разными источниками данных в "формате ISO 15926". Ибо сейчас нет ни одного средства моделирования, которое бы выдавало корректный с точки зрения OMG xmi. Поэтому при подаче заявок, специально обученные люди руками правят файл экспорта,сгенерированный тулой, что используется для моделирования. Ближе всех к корректной версии приближается сейчас MagicDraw, поэтому используют обычно его.

Тут ехидно замечу, что в наша софтинка по факту используется уже некоторыми фирмами для проверки правильности сгенерированных ими файлов ISO 15926 и тем самым по факту является эталоном имплементации. Это лишь значит, что если мы пойдём этим трудным путём MOF, то нам придётся и там стать эталоном реализации, не опускать же планку :-)

Пункт 2 с теми же полномочиями - платиновые грабли полувековой давности. Можно с другими полномочиями - как у Wolfram, с обязательным показом/подтверждением формальной интерпретации неформальных пользовательских пожеланий.
Пункт 7 - у SPARQL неисправимые проблемы в спецификации, которые на уровне имплементаций не решаются. Всегда будет долго и затратно. Поддержка трансляции подмножества сканера в SPARQL может быть маркетинговым решением, не более.

Идеи есть, но более простые, и вероятнее к 1.3:
1. Загрузка файлов с автодетектом: темплейты, датасет, их смесь, или семантиквеб-помойка неизвестного происхождения.
2. Загрузка как readonly напрямую из архивов.
3. Создание архива из выбранных файлов проекта (включая те, что открыты из других архивов).

Плюс:
4. Расширение автодетекта, возможность пакетной _синтаксической_ верификации (файла, группы файлов, всего содержимого каталога, ...). Редактор всеяден, а вот верификация должна ругаться на семантиквебовщину, или что вместо темплейтов по 15926-8 где-то попался древний формат iRINGTools.

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

Фишка была бы в том, чтобы как-то это делать чуть быстрей, чем просто руками хакать ввод каждый раз.

кодогенерацийа, в смысле трансляцийа из моделей в какие-то другие модели, например в код

очень тяжело продираться, сквозь аглицкий. далеко не всё на Русском.

Конечно, далеко не всё на русском. Документацию на .15926 Editor мы сразу на английском пишем, на русском её вообще нет. Да и сам стандарт весь на английском, и JORD RDL на английском, и даже книжка BORO. Так что "далеко не всё" я бы считал очень, очень мягкой формулировкой.

  • 1