Языки программирования и автомобили


Содержание

Топ-5 языков для машинного обучения

Существует великое множество языков программирования, однако не все они подходят для машинного обучения (МО). Портал Techopedia рассказывает о наиболее подходящих языках, их преимуществах и недостатках.

Специалист по вычислительной техники Стэнфордского университета Эндрю Нгом дал МО следующее определение: «наука, которая работает над тем, как научить компьютеры функционировать без явного программирования». Предпосылки к рождению науки появились в однако вплоть до начало они носили лишь теоретический характер. Настоящий прорыв произошел десятилетие назад, когда МО стало катализатором развития нескольких прорывных технологий, особенно это касается искусственного интеллекта. МО можно разбить на несколько категорий, включая контролируемое (supervised), неконтролируемое (unsupervised), полууправляемое (semi-supervised ) и обучение с подкреплением (reinforcement learning).

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

МО в современной итерации востребовано во многих отраслях промышленности, растет также спрос на продукты и услуги, основой которых являются машинные алгоритмы. Предприятия применяют прогностические возможности МО, стремясь разработать предписывающие (prescriptive) методы для принятия обоснованных решений. Технология предусматривает несколько методов разработки ПО на базе машинных алгоритмов, однако самым популярным из них является задействование языков программирования.

Python. Это высокоуровневый язык программирования, который имеет множество различных способов применений, включая науку о данных и внутреннюю веб-разработку. Он был создан Python Foundation в начале и является мощным инструментом для анализа данных, широко используется в технологии больших данных. Особый статус ему придает многочисленное сообщество разработчиков МО, которое в основном сосредоточено на быстрорастущем ИИ-направлении.

Благодаря активному сообществу для Python появилось множество готовых библиотек МО. Этот язык — платформенно независимый, поэтому его можно адаптировать практически к любой операционной системе. Еще одно преимущество Python связано с его открытостью — он построен на базе технологий Open Source, поэтому разработчики могут получить доступ к любому стеку языка.

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

R. Этот язык программирования появился в начале и является частью проекта GNU. Он широко применяется в анализе данных и, как правило, является целевым для решения общих задач МО, таких как регрессия, классификация и формирование дерева решений. R помимо прочего пользуется популярностью среди статистиков. Как и Python, R обладает открытым исходным кодом и широко известен как язык, пакеты для работы с которым относительно легко установить, настроить и применять.

R — платформенно независимый, он хорошо интегрируется с другими языками программирования. Наряду с анализом данных, R приспособлен для визуализации данных.

Несмотря на относительную простоту интеграции с другими инструментами, R обладает рядом особенностей, которые усложняют его изучение. К ним, например, можно отнести нетрадиционные структуры данных и индексирование (которое начинается с 1 вместо 0).

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

JavaScript. Этот язык появился в середине как инструмент для улучшения практики веб-разработки и является одним из наиболее востребованных в этой области. JavaScript — высокоуровневый и динамически типизированный язык, гибкий и мультипарадигмальный. Применение языка в МО получило ограниченное применение, но, тем не менее, такие известные проекты, как Google Tensorflow.js, основаны на JavaScript.

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

C++. Это самый старый среди наиболее распространенных на сегодняшний день языков программирования. Он был создан в недрах Bell Labs в начале как научно-исследовательский проект, направленный на расширение возможностей языка Си. Обладая возможностями одновременно как низкоуровневого, так и высокоуровневого языка программирования, в контексте МО C++ обеспечивает более высокий уровень контроля и эффективности, чем другие языки программирования.

Гибкость языка хорошо подходит для ресурсоемких приложений, и подмножество программ МО здесь — не исключение. Учитывая, что C++ — статически типизированный язык, он может выполнять задачи с относительно высокой скоростью.

Что касается его минусов, то основным из них является то, что для создания новых приложений на базе C++ требуется написание большого объема сложного кода, что занимает много времени и может вызвать большие трудности в обслуживании. Язык C++ определенно сложен в овладении и, создавая на нем новые проекты, начинающие программисты очень часто допускают невынужденные ошибки.

Java. За созданием Java стоит Sun Microsystems. Появившийся в середине он изначально замышлялся как высокоуровневый и объектно-ориентированный язык программирования, который во многом напоминает по структуре C++. Обладая огромной популярностью, Java может похвастаться широким спектром алгоритмов, которые очень полезны для сообщества разработчиков софта МО. Во многом Java считается одним из самых безопасных языков программирования благодаря использованию байт-кода и песочниц.

Его можно обозначить как удачную инкарнацию C++ (Java обладает большинством функционала, заложенным в C++), которая лишена недостатков последнего — проблем с безопасностью кодовой базы и сложностью компиляции.

Несмотря на все свои преимущества, Java имеет репутацию более медленного языка, чем многие другие языки программирования и в том числе C++. Кроме того, начиная с 2020 г. для написания определенных бизнес-приложений на Java требуется коммерческое лицензирование, что выльется в дополнительные расходы для предприятий.

Выводы

Python — самый популярный из всех языков программирования, применяемых в МО. Тем не менее, сбрасывать со счетов JavaScript и ряд некоторых других языков, может быть непредусмотрительно. Это связано с тем, что со временем их популярность будет расти, отражая изменения бизнес-ландшафта. Что касается тенденций программирования, то можно с уверенностью сказать, что в ближайшие несколько лет написание кода останется востребованной функцией, однако оно станет менее ориентированным на код и больше на функционал, поскольку машины сами научатся писать код.

Разработка программы для ЭБУ автомобиля

Решил попробовать разработать программу для ЭБУ автомобиля.
Думаю писать на C#.
Но даже не знаю с какого конца подойти.

Буду благодарен за любую информацию с чего начинать, что надо делать, как подключаться и прочее.

Так как подходящего раздела не нашел, решил создать тему в этом.

Комментарий модератора
Тема перенесена из раздела C# .NET.
15.04.2011, 18:59

Разработка программы прокладки курса внедорожного автомобиля при гонках по бездорожью
Курсова робота тема:»Разработка программы прокладки курса внедорожного автомобиля при гонках по.

ЭБУ для 2Т двигателя
На Atmega16A хочу собрать блок управления двухтактным двигателем. Программировать собираюсь на Си.

Написание программы с использованием файловых переменных. Разработка программы для работы с текстовым файлом
Помогите пожалуйста : С помощью текстового редактора создать текстовый файл file1. Переписать.

Разработка программы для для слияния двух текстовых файлов
Требуется программа для слияния двух текстовых файлов. Условие задачи: «Разработать программу.

C++ разработка программы для ввода информации
Разработать программу для ввода информации о продажах торговой фирмы за несколько последовательных.

Если бы языки программирования были автомобилями

C: Формула-1 образца 1972-го года. Все еще очень быстро ездит, но в неумелых руках становится орудием самоубийства.
C++: КАМАЗ. Может везти большой груз, но выпускает ужасный выхлоп и часто ломается.
Java: китайский бортовой грузовик-воровайка. Дешевый, доступный, но не такой быстрый, как бы хотелось, требует периодического ремонта. За неимением лучшего используется для разгрузки бревен на ближайшей пилораме.
Pascal: ВАЗ-2106. Воспоминания о нем вызывают ностальгию.
Perl: УАЗ 90-х годов. Все еще на ходу, но большинство предпочитает что-то более комфортное.
Python: Toyota Corolla. Автоматическая трансмиссия, 6 подушек безопасности. Не поедет, пока не пристегнетесь. На нем вы ездите на работу и в ближайший супермаркет. Иногда вам хочется чего-то более экстремального.

Кто хочет продолжить?

Паскаль реально вызывает тёплые ламповые чувства.

Электромобиль стало быть :)

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

FORTRAN: мотоцикл с коляской «Урал».

BASIC: улучшенный FORTRAN — с застеклённой коляской, металл конструкции заменён на пластик.

Ada-95: часть ракеты Ariane 5, на дорогах общего пользования не замечен.

Modula-3: трансформер из 90-х, на дорогах общего пользования не замечен.

JavaScript: буер с парусом.

PHP: Ford focus, едет и хрен с ним.

Lua: это такой конструктор, с помощью которого вы сможете добавлять, удалять и изменять особенности машины и её поведение без обращения на завод, более того, прямо на ходу =)

Rust: постапокалиптический багги собранный опытным механиком. Все бы хорошо, если бы механик не был одноногим алкашом и собирал бы машину не из частей найденных на свалке.

CL: Toyota AE86. Не способна передвигаться иначе как боком. Из салона всегда на полной громкости играет евробит.

JavaScript: Lifan с выпадающим движком.

Программное обеспечение автомобиля

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

Содержание обзора:

  • Особенности автомобильного софта
  • Основные состовляющие ECU
  • Процессы и технология
  • Управление двигателем
  • Стандартизация
  • Видео — 5 нужных лайфхаков для автомобиля

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

Особенности автомобильного софта

Современное программное обеспечение для вашего автомобиля весьма надежно: коэффициент сбоя оборудования — всего лишь один на миллион операций в течение года, и то в качестве исключения.

Взаимодействие между этими блоками выполняется благодаря шинным архитектурам, которые представляют собой совокупность контроллеров — CAN, controller area network, а также специальную сеть, предназначенную для передачи информации специального цифрового оборудования — MOST, media-oriented systems trans, FIexRay, а также систему Local interconnect, (LIN).

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

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

  • Надежность — системные программы автомашины в достаточно сложной сети ECU в продолжение всего периода использования должны работать максимально надежно;
  • Безопасность выполняемых функций — ESC и система торможения должны действовать безотказно, и это уже предполагает довольно серьезные требования к ПО и к самому процессу их разработок;
  • Скорость взаимодействия – мгновенная реакция электронных узлов автомобиля (до миллисекунд) невозможна без специальной программной архитектуры и усовершенствованных операционных систем;
  • Надежная архитектура — ПО автомобиля должно осуществлять максимальную электромагнитную совместимость, а также не поддаваться влияниям искаженных сигналов;
  • Связь узлов электронно-механического цикла.

Внимание: Ни в коем случае не допускать перезагрузку ECU во время работы!

Основные составляющие ECU

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

    Аналого-цифровой преобразователь(ADC) — это оборудование предназначено для снятия показателей с определенных автомобильных датчиков, и с датчика кислорода в том числе. Дело в том, что процессор способен воспринимать только цифровые значения, а, например, показатель кислорода выдает лишь электрические сигналы напряжением от 0 до 1,1V. ADC преобразует эти данные в десятибитное двоичное число, и оно становится понятным для процессора.

Драйвер – программа, предназначенная для управления цифровым оборудованием за счет преобразования сигналов.

Цифро-аналоговый преобразователь (DAC) — предоставляет аналоговые сигналы, чтобы запустить определенные компоненты двигателя автомобиля.

  • Чип связи – эти чипы позволяют реализовать самые разные стандарты связи, имеющиеся в автомобиле. В производстве имеется несколько таких стандартов, но самым распространенным из них является CAN — Controller-Area Networking. Он обеспечивает скорость 500 к/бит в секунду, что крайне необходимо для модулей, которые совершают до сотни операций в ежесекундно.
  • Процессы и технология

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

    Изначально в прошлом столетии в качестве ПО использовался ассемблер. Язык же Си стал распространяться в 90-е годы. Компания Robert Bosch и многие другие производители начали разрабатывать ПО с помощью Mathlab/Simulink и ASCET (управляющие и моделирующие технологии).

    Системы шин CAN делают ПО автомашины достаточно сложным. Причина заключается в том, что они не исключают взаимодействия между программами разных ECU. Современные автомобили класса люкс могут содержать сложную сеть, состоящую из 80 ECU, которые в общей сложности имеют до 100 млн. строк кода.

    Инженерные решения на уровне процессов и архитектуры тоже становятся одним из главных условий аутсорсинга. В связи с этим обстоятельством компания Bosch некоторые разработки начала отдавать на сторону еще с начала 90-х годов прошлого столетия.

    В настоящее время работа над ПО для автомашин проводится несколькими объединениями, распределенными по всему миру. И такого рода деятельность стала довольно оптимальной для бизнеса.

    Управление двигателем

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

    Например, современные дизельные двигатели способны впрыскивать топливо в минимальном количестве семь раз за один такт. А это для двигателя с четырьмя цилиндрами, который развивает скорость вращения до 1800 оборотов в минуту, составляет 420 раз в секунду. Все это требует новых функций ПО и более продуманных алгоритмов управления, чтобы любые отклонения свести к минимуму.

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

    Центром управления трансмиссиями автомашин является модуль управления двигателем. Современные модули имеют объем более 2 мегабайт цифровой памяти и функционируют с частотой тактов до 160 МГц. При этом задействуются программы до 300 тыс. строк кода.

    Стандартизация

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

    В 2003 году поставщиками и производителями было создано объединение «Automotive Open System Architecture»(Autosar). Цель создания организации – выполнение общего стандарта и единых технологий. Сегодня это объединение охватывает свыше 150 организаций, которыми сообща разрабатывается новое строение ECU, базовое ПО и все необходимое для создания рабочего программного обеспечения.

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

    Строение Autosar состоит из нескольких абстрактных уровней, в которых ПО отделяется от аппаратного обеспечения. На самом верху находится прикладное ПО, которое реализует всю прикладную деятельность. Ниже следует базовое, номинальное ПО. Оно гарантирует нужную абстракцию от аппаратного обеспечения точно так же, как это происходит, например, в персональном компьютере. Autosar Runtime Environment (среда исполнения в реальном времени) осуществляет связи внутри ECU.

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

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

    Например, водитель во время следования отвлекся на пассажира. В этом случае приложение определяет торможение движущегося впереди автомобиля, затем предупреждает водителя или самостоятельно включает торможение. Кстати, водитель может даже сразу не узнать о наличие такого ПО, пока не окажется в опасном положении.

    Заключение

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

    5 нужных лайфхаков для автомобиля — в видео:

    Автомобильный справочник

    для настоящих автомобилистов

    Автомобильное программное обеспечение

    Первое автомобильное программное обеспечение появилось в автомобилях еще в 60-х годах. Благодаря этому отрасль серьезно изменилась – сегодня электроника, и особенно программное обеспечение, являются основными источниками инноваций. Автомобильное программное обеспечение повышает надежность с помощью систем активной и пассивной безопасности, таких как антиблокировочная тормозная система и электронная система курсовой устойчивости (ESC). Кроме того, происходит постепенная интеграция бытовой электроники в автомобили.

    Разработка автомобильного программного обеспечения

    Любая разработка программного обеспечения имеет целью создание новой или улучшение существующей функ­ции. Такие функции создают дополнитель­ные плюсы и удобства для водителя, других пассажиров, механиков СТО, перевозчиков, обеспечивают соответствие требованиям за­конодательства, упрощают обслуживание или повышают эффективность проектирова­ния и изготовления. Техническая реализация может быть механической, гидравлической, электрической или электронной. Часто ком­бинируют сразу несколько этих технологий, а ключевую роль в реализации многих автомо­бильных новшеств все чаще играет электро­ника. Благодаря использованию электрики, электроники и программного обеспечения — логического ядра систем — экономически эф­фективно реализуются «интеллектуальные» функции привода, шасси и остальной части автомобиля.

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

    Требования к программному обеспечению в автомобиле

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

    Автомобильное программное обеспечение используется во многих вариантах автомобиля и даже мо­дельных рядах. Поэтому оно должно легко адаптироваться к соответствующим систе­мам. Для этого оно содержит параметры калибровки и программные карты. Их количество в автомобиле может достигать не­скольких десятков тысяч. Эти регулируемые переменные имеют множество взаимных за­висимостей. К тому же постоянно увеличива­ется степень связи отдельных систем между собой. Все чаще одна функция распределя­ется между несколькими системами или ЭБУ.

    Программное обеспечение в автомобиле большей частью разрабатывается под кон­кретные области применения и интегрируется в единую систему. Его еще называют встроенным программным обеспечением, «зашитым» в постоянное запоминающее устройство. Многие функции часто раз­рабатываются и дорабатываются в течение длительного времени во многих уголках мира. Поскольку запасные части должны оставаться в наличии даже после заверше­ния производства конкретного автомобиля, электроника в автомобиле должна иметь относительно длительный срок службы — до 30 лет .

    Из соображений экономии в ЭБУ зачастую содержатся микроконтроллеры с ограничен­ной вычислительной мощностью и ограни­ченным объемом памяти. Во многих случаях для этого требуются меры по оптимизации разработки программного обеспечения для сокращения количества необходимых аппа­ратных средств.

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

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

    Структура программного обеспечения в автомобилях

    Программное обеспечение в автомобиле со­стоит из множества компонентов. Как и в случае с персональным компьютером, различают «воспринимаемые функции» про­граммного обеспечения, прикладное про­граммного обеспечения и платформенное программное обеспечение, частично завися­щее от аппаратной части (рис. «Основные компоненты статичной программной архитектуры для микроконтроллеров и стандартизованных программных компонентов» ). Взаимодей­ствие между всеми функциями определяется в архитектуре. Здесь могут быть различные отображения. Статичное отображение иерар­хически описывает функциональные группы, сигналы и распределение ресурсов. С другой стороны, функциональное отображение опи­сывает прохождение сигнала через различ­ные функции. Динамическое отображение, т.е. зависимое от времени, анализирует от­клик при выполнении различных задач. Уже на раннем этапе введены стандарты для обе­спечения взаимодействия между отдельными компонентами и их дальнейшего раз­вития. Наиболее важные стандарты описаны ниже.

    Важные стандарты для автомобильного программного обеспечения

    Органы и комитеты

    Ассоциация стандартизации автоматизи­рованных и измерительных систем (ASAM) занимается стандартизацией в автомобиль­ной промышленности применительно к мо­делям данных, интерфейсам и синтаксису. ASAM разработала различные стандарты для подключения ЭБУ к компьютеру или тер­миналу ввода данных. Стандарт ASAM-MCD1 (MCD — измерение, калибровка и диагно­стика) поддерживает различные протоколы передачи данных. При использовании спец­ификаций ASAM-MCD2 можно обращаться к двоичным данным в ЭБУ и одновременно отображать соответствующие данные в виде физических значений и обрабатывать их. Стандарт ASAM-MCD3 также позволяет ав­томатизировать такие процессы, например, для автоматической калибровки данных. Есть и другие стандарты ASAM, регламен­тирующие, к примеру, обмен функциональ­ными описаниями и данными.

    Консорциум FlexRay разработал специфика­цию для полевой шины FlexRay для регули­рования по разомкнутому и замкнутому (с обратной связью) циклу в автомобилях. Благодаря высокой скорости передачи дан­ных с запрограммированным арбитражем шины и отказоустойчивой конструкции она особенно подходит для использования в си­стемах активной безопасности и в системе привода.

    Международная электротехническая ко­миссия (IEC) устанавливает стандарты в области электротехники и электроники. IEC предлагает три системы анализа, с помо­щью которых можно проверить соответствие международным стандартам. IEC работает в тесном взаимодействии с международной организацией по стандартизации (ISO), международным телекоммуникационным союзом (ITU) и многочисленными органами стандартизации (в том числе Институтом инженеров-электриков и электронщиков, IEEE).

    Ассоциация разработчиков программного обеспечения для автомобилей (MISRA) — ор­ганизация в автопромышленности, устанав­ливающая правила для разработки и внедре­ния надежного программного обеспечения в автомобильных системах. Самым из­вестным является стандарт программирования MISRA-C, разработанный компанией MISRA. Он предписывает правила надежного программирования на языке С. Цель этого стандарта — избежать ошибок п ер иода испол­нения из-за ненадежных конструкций языка С и возникновения слабых мест в структуре из-за непонимания между программистами, и защитить правильность выражений. Многие правила могут автоматически проверяться и учитываться при генерировании кодов.

    Сообщество автомобильных инженеров (SAE) — международная научно-техническая организация, работающая в области технологий для обеспечения мобильности. По­мимо прочего, оно устанавливает стандарты для автомобильной промышленности и спо­собствует обмену знаниями.

    Стандартизационный орган «Открытые си­стемы и их интерфейсы для автомобильной электроники» (OSEK) появился из проекта немецкой автомобильной промышленности. Позже появилась инициатива «Vehicle Distributed Executive» (VDX) французской автомобильной промышленности. Стандар­тизация базовых компонентов программного обеспечения осуществляется под эгидой OSEK/VDX в следующих областях:

    • Связь (обмен данными внутри и между ЭБУ);
    • Операционная система (выполнение в ре­альном времени программ ЭБУ и базовых услуг для других модулей OSEK/VDX);
    • Управление сетью (конфигурация и кон­троль).

    Архитектура программных платформ для япон­ской автомобильной промышленности (JasPar) — инициатива для сокращения расходов и технологий разработки в автомобильной электронике. Она поощряет японские компа­нии совместно разрабатывать технологии, не имеющие отношения к конкуренции, такие как сетевые решения, сервисные функции и базо­вое программное обеспечение. JasPar работает в тесном сотрудничестве с AUTOSAR и FlexRay.

    AUTOSAR

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

    Главным для AUTOSAR является логическое распределение между базовым программным обеспечением (BSW) для конкретных ЭБУ и прикладным программным обеспечением, не­зависимым от ЭБУ (ASW) и их соединение по виртуальной системе шин (VFB) (рис. «Архитектура AUTOSAR» ). Эта виртуальная шина также соединяет компоненты программного обеспечения, реализованные в разных ЭБУ. Таким образом, их можно смещать между разными ЭБУ без необходимости вно­сить изменения в сами компоненты программ­ного обеспечения. Это может быть полезно при оптимизации вычислительной мощности, требо­ваний к памяти и коммуникационной нагрузки.

    Функциональные программные компо­ненты (SWC) строго разграничиваются между собой и с базовым программным обеспече­нием. Они, как правило, содержат конкрет­ные алгоритмы управления, выполняемые во время прогона программы. Они сообщаются через интерфейс AUTOSAR с другими функ­циями и интерфейсами ЭБУ. Эти интерфейсы (API) определяются в описаниях SWC XML.

    Среда прогона программы (RTE) обе­спечивает связь между функциональными компонентами программного обеспечения и соответствующим базовым программным обеспечением на ЭБУ. RTE адаптируется к конкретному ЭБУ и области применения. Она может в большой степени создаваться авто­матически из требований к интерфейсу.

    Базовое программное обеспечение содержит программные части для конкретных ЭБУ — ин­терфейсы связи, диагностику и управление памятью. Базовое программное обеспечение также содержит слой сервисов. Это программ­ное обеспечение сочетает в себе программные компоненты для общих сервисных функций (SRV), связи (СОМ) и операционной системы, частично зависящей от используемого ЭБУ (OS). Последняя базируется на операционной система OSEK/VDX. В этой области ресурсы ЭБУ группируются и управляются таким образом, чтобы получить оптимальную сетевую под­держку, управление памятью, диагностику и пр. Используемые аппаратные средства заключа­ются в два слоя со взаимной зависимостью. Абстракция микропроцессора (MCAL) с прямым доступом к интерфейсным модулям ЭБУ про­должается в еще одном слое (абстракция ЭБУ). Драйверы сложных устройств (CCD) обеспечи­вают прямой доступ к ресурсам микроконтрол­лера для приложений с особыми требованиями к функциональности и выбору времени. Они также являются неотъемлемой частью базового программного обеспечения, т.е. прикладное про­граммное обеспечение можно разрабатывать независимо от аппаратной части, даже когда требуются услуги драйверов сложных устройств.

    Помимо архитектуры ЭБУ, AUTOSAR ча­стично стандартизирует также методы раз­работки. Это прежде всего относится к структуре и зависимостям различных рабочих продуктов (например, файлов). Они нужны для создания выполнимых программ для со­ответствующих ЭБУ из разных описаний про­граммных компонентов.

    Стандарты диагностики

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

    Рабочая группа Automotive Electronics (ASAM-AE) разработала три специфика­ции для программных средств диагностики автомобилей, публикуемых в виде междуна­родных стандартов в группе стандартов ISO 22900:

    • Интерфейс между средой прогона и устройствами связи (MCD-1Dи PDU-API, ISO 22900);
    • Стандарт ODX для обмена данными диагно­стики, например, для передачи данных на тестер СТО (MCC-2D, ISO 22901);
    • Интерфейс объектно-ориентированного программирования (MCD-3D, ISO 22900) для диагностических приложений, таких как, например, диагностика с подсказками.

    Стандарт MCD-1C учитывает существую­щие стандартные инструменты, например, устройства для программирования ЭБУ.

    В настоящее время в рамках проекта стандарта ISO разрабатываются требования к формату обмена, «Коммуникационный формат последовательной проверки на от­сутствие разрывов» (ОТХ), для создания, использования и обмена диагностическими программами.

    Процесс разработки про­граммного обеспечения для автомобиля

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

    Для удовлетворения приведенных выше требований в разработке программного обе­спечения для автомобилей неотъемлемой ча­стью разработки, в дополнение к технологии и инструментам, являются определяемые по­следовательности (процессы).

    Модели для описания процессов

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

    Принцип V-модели

    Описанное здесь V-образное отображение процесса разработки используется во многих вариациях и степенях детализации. V-модель Федерации проектирования и реализации в сфере информационных технологий прави­тельства Германии здесь описана не бу­дет.

    V-модель распределяет этапы процесса, связанные непосредственно с разработкой, по лучам воображаемой буквы V, где по оси х отображается ход разработки, а по оси у — степень детализации соответствующего этапа (рис. «Расширенная V-модель» ). Этап процесса можно описать необходимыми вводными переменными, процедурой, методами, ролями, инструментами, критериями качества и выходными пе­ременными. Этапы процесса, определяемые на левом луче латинской V, проверяются на ее правом луче. Эти этапы могут также про­ходиться несколько раз или быть поделены на части.

    В расширенной V-модели можно рассмо­треть сопутствующие процессы — например, запрос, изменение, управление проектом и качеством.

    Модели для оценки процессов

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

    ISO 9000 и TS 16949

    Ориентированный на процессы стандарт EN ISO 9000 регламентирует требования к си­стеме управления качеством. Акцент здесь делается на взаимодействия и интерфейсы. Изначально акцент делался на производство и интерфейсы заказчика.

    Техническая спецификация ISO/TS16949 была разработана североамериканской и европейской автомобильной промышленностью устанавливает требования к системам управления качеством. Цель этого стан­дарта — эффективное повышение качества системы и процессов для повышения сте­пени удовлетворенности клиентов, выявле­ния сбоев и рисков в производственном про­цессе и каналах сбыта, устранения их причин и проверки эффективности коррекционных и профилактических мер. Сутью специфика­ции является не выявление, а скорее предо­твращение сбоев. Соответствие ISO 9000 и TS 16949 можно проверить путем сертификации.

    CMMI

    CMMI — это модель для оценки и систе­матической оптимизации организаций- разработчиков и их процессов, изначально разработанная Институтом раз­работки программного обеспечения (SEI). Она описывает набор требований к процес­сам и их зависимости (рис. «Обзор процесс CMMI. ML-уровень зрелости» ). CMMI обеспе­чивает рамки, реализация которых требует ориентированной на бизнес интерпретации и организации содержания. Она описывает то, что необходимо сделать. Организация должна соответствующим образом описать, «как» это необходимо сделать. Содержание модели CMMI базируется на передовых ме­тодах организации работы, т.е. «лучших ме­тодах». CMMI обеспечивает процедуру для оптимизации процессов на долгосрочную перспективу от пути развития организации до обучения организации.

    CMMI имеет много общего в плане содер­жания с ISO 9000/TS 16949. В этом контексте CMMI имеет большую степень детализации, в то время как ISO 9000/TS 16949 охватывает более широкий спектр областей применения.

    CMMI различает пять уровней зрелости (ML) подразделения организации (рис. «Уровни зрелости CMMI» ). Рассматриваются различные области про­цесса, в зависимости от уровня зрелости. Уровень зрелости считается достигнутым, когда все соответствующие области процесса отлажены и проверены системой оценки. Для выхода на более высокий уровень зрелости нужно еще раз проверить области процесса нижнего уровня.

    CMMI используется в качестве оптимизационной-оценочной модели для организаций-разработчиков и обеспечивает хорошую поддержку при оптимизации про­цессов во всех подразделениях организации и оценке поставщиков.

    Automotive SPICE

    Аббревиатура SPICE расшифровывается как «совершенствование процессов в разработке программного обеспечения и определение возможностей». Automotive SPICE — это «ав­томобильный» вариант международного стандарта ISO/IEC 15504 (Процессы при раз­работке программного обеспечения). Это модель для оценки, с учетом специфики про­екта, процессов, имеющих место при разра­ботке программного обеспечения. Она, как и CMMI, концентрируется на требованиях к систематической разработке. Поэтому содер­жание моделей Automotive SPICE и CMMI очень похоже. Automotive SPICE больше кон­центрируется на требованиях к уровню и дает меньше возможностей для ориентированной на бизнес интерпретации требований. Automotive SPICE фокусируется (в настоящее время) только на программном обеспечении и только на отдельных проектах. Напротив, области применения CMMI шире и охваты­вают любые работы и услуги в сфере разра­ботки и руководство ими. Automotive SPICE используется автопроизводителями в каче­стве модели для оценки проектов и постав­щиков в области разработки программного обеспечения.

    Оценка процессов выполняется с помощью двухразмерной модели. Понятие «размер процесса» служит для определения и выбора анализируемых процессов, а «размер уровня зрелости» — для определения и оценки их со­ответствующей возможности. Размер уровня зрелости состоит из шести ступеней уровня зрелости — «не завершено», «выполнено», «проконтролировано», «установлено», «предсказуемо» и «оптимизация».

    Контроль качества при разработке программного обеспечения

    Как и в случае с любым техническим про­дуктом, при разработке автомобильного программного обе­спечения также используется множество ин­струментов для контроля качества. В отличие от механики и электрики, контроль качества играет менее значительную роль в созда­нии программного обеспечения, поскольку оно относительно легко воспроизводится. Важными моментами здесь являются общая функциональность системы, стандарты каче­ства, овладение сложностью и применение. Поскольку программное обеспечение в авто­мобиле также охватывает системы, имеющие отношение к безопасности — например, си­стему управления динамикой и системы по­вышения безопасности при движении (DAS), контроль качества играет важную роль. Кроме того, очень важное значение имеет экономическое представление качества про­граммного обеспечения, особенно в сложных системах.

    ISO 61508 и TS 26262

    В настоящее время автомобильная промыш­ленность разрабатывает стандарт ISO 26262 (Транспортные средства — функциональная безопасность) для проектирования имеющих отношение к безопасности электрических и электронных систем в автомобилях на базе стандарта IEC 61508 (Функциональная безо­пасность электрических / электронных / про­граммируемых электронных систем, имею­щих отношение к безопасности). Он включает в себя требования и к продукту, и к процессу разработки, и охватывает концепцию, проек­тирование, разработку, реализацию, запуск, обслуживание, модификацию, выключение и демонтаж как самой системы, имеющей от­ношение к безопасности, так и систем, умень­шающих риск. Стандарт обозначает эти этапы в целом как «полный жизненный цикл безо­пасности». Продукты делятся на уровни инте­грации безопасности SIL1 — SIL 4 (ISO 61508) и автомобильные SIL, ASIL А — ASIL D (ISO 26262). SIL 1 и ASIL А, являются самым низ­ким, a SIL 4 и ASIL D самым высоким уровнем интеграции безопасности.

    Процессы разработки программного обеспечения для автомобилей

    Междисциплинарная кооперация в разра­ботке (например, между разработкой при­вода и электроники), распределенная разра­ботка (например, между поставщиком и автопроизводителем или разработка в раз­ных местах) и длительные жизненные циклы элементов программного обеспечения тре­буют общего понимания задач в целом. На­пример, при проектировании автомобильных функций управления с обратной связью и без нее, также должен обеспечиваться общий обзор всех требований к надежности и безо­пасности, а также аспектов реализации про­граммного обеспечения. Для этого во многих областях используется разработка программ­ного обеспечения на базе моделей (рис. «Этапы разработки программных функций на основе моделей» ).

    Разработка программного обеспечения на базе моделей

    Различают две области разработки про­граммного обеспечения на базе моделей. Логическая системная архитектура содержит и описывает виртуальную область моделей, в то время как техническая системная архитек­тура содержит реальные ЭБУ и автомобили. Логическая системная архитектура отобра­жается серым цветом, а техническая систем­ная архитектура — белым. Эта процедура опи­сывается функциями управления с обратной связью и без обратной связи, но подходит также и для общей реализации функций — например, для контроля и диагностики.

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

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

    На следующем этапе виртуальные модели среды, при необходимости дополняемые ре­альными компонентами, такими как фор­сунки, имитируют среду ЭБУ, тем самым по­зволяя проводить циклические лабораторные испытания формата «In-the-Loop». По срав­нению с испытаниями на стенде и на дороге они повышают гибкость и глубину испыта­ний, упрощая их воспроизводимость. Калибровка функций программного обеспече­ния в электронной системе должна учитывать настройки, относящиеся к конкретному авто­мобилю — например, параметры, записанные в виде характеристических значений, кривых и карт этих функций. Во многих случаях это сопо­ставление происходит лишь на более поздней стадии разработки; зачастую прямо в автомо­биле во время работы систем. Однако усилива­ется тенденция к более ранней (предваритель­ной) передаче данных; т.е. уже на ранних этапах разработки как можно более реалистичные ка­либровочные данные определяются с помощью моделей или эмпирических значений. Из-за множества калибровочных переменных и вза­имной зависимости для калибровки требуются подходящие процедуры и инструменты, потому что в конечном итоге качество калибровки, т.е. точная адаптация программного обеспечения к автомобилю, определяет степень использо­вания потенциала программного обеспечения.

    Функциональные сети и сети ЭБУ

    Эта процедура может также применяться к разработке функциональных сетей и сетей ЭБУ. Однако в этих случаях появляются до­полнительные аспекты, например:

    • Комбинации смоделированных, виртуаль­ных компонентов и функций, уже реализо­ванных в коде ЭБУ;
    • Комбинации смоделированных, виртуаль­ных и реализованных механических ком­понентов и устройств.

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

    Моделирование и имитация программных функций

    Моделирование систем управления автомобиля

    Для моделирования систем управления с об­ратной связью и без обратной связи следует по возможности использовать блок-схемы. В этих схемах для отображения отклика компонентов используются блоки, а для ото­бражения потока сигналов между блоками — стрелки (рис. «Моделирование с блок-схемами и имитацией» ). Поскольку большинство систем многовариантны, то все сигналы обычно представлены в виде векторов. Они классифицируются на:

    • Измерительные переменные или переменные обратной связи у;
    • Выходные переменные с управлением без обратной связи или с обратной связью u*
    • Контрольные или заданные переменные w;
    • Значения, задаваемые водителем w*;
    • Переменные с управлением без обратной связи или с обратной связью у*:
    • Регулируемые переменные u
    • Значения возмущений z

    Блоки классифицируются на:

    • Блоки с управлением без обратной связи или с обратной связью;
    • Модели исполнительных механизмов;
    • системная модель;
    • Модели генераторов заданных значений и датчиков;
    • Модель водителя и окружающей среды.

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

    Создание прототипа быстрого управления программными функциями

    Создание прототипа быстрого управления в этом контексте включает в себя все методы для ранней реализации спецификаций для функций управления без обратной связи или с обратной связью в реальном автомобиле. Для этого в испытании должны быть реализованы смоделированные функции управления без обратной связи или с обратной связью. В каче­стве платформы для реализации программ­ных частей функций управления без обратной связи или с обратной связью можно использо­вать экспериментальные системы (рис. «Создание прототипа быстрого управления программных функций в реальном автомобиле» ).

    Экспериментальные системы соединя­ются с генераторами заданных значений, датчиками и исполнительными органами, а также другими автомобильными ЭБУ, отно­сящимися к общей системе. Интерфейсы с реальным автомобилем означают, что про­граммные функции, реализованные в экспе­риментальной системе — и в ЭБУ — учитывают потребности в реальном времени.

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

    Экспериментальные системы с модульной структурой можно конфигурировать под конкретную область применения — например, под необходимые интерфейсы для сигналов ввода-вывода. Вся система рассчитана на ис­пользование в автомобиле и управление от компьютера, например, персонального. Это позволяет тестировать спецификации про­граммных функций на ранней стадии прямо в автомобиле. Затем спецификации могут, при необходимости, быть изменены.

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

    Процедура обхода

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

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

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

    Можно также скомбинировать обход от­дельных частей программного обеспечения с полной поддержкой всего программного обеспечения в целом, что повышает гибкость.

    Приложения обхода

    Приложения обхода подходят для раннего те­стирования дополнительной или модифициро­ванной программной функции автомобильного ЭБУ. Новая или модифицированная программ­ная функция определяется моделью и рабо­тает в экспериментальной системе. Для этого требуется ЭБУ, способный выполнять базовые функции программного обеспечения, поддер­живать все необходимые генераторы заданных значений, датчики и исполнительные органы и обеспечивать интерфейс обхода для экспери­ментальной системы. Новая или модифициро­ванная программная функция разрабатывается с помощью создания прототипа быстрого управления. В этом случае она выполняется в экспериментальной системе (рис. «Разработка прототипа с системой обхода» ).

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

    На функцию обхода можно также повлиять через автомобильную шину (например, CAN). Возможен даже доступ к центральному про­цессору ЭБУ через интерфейсы микрокон­троллера посредством эмулятора.

    Приложение с полной поддержкой

    Если в автомобиле должна тестироваться со­вершенно новая функция, а ЭБУ с интерфейсом обхода нет, то испытания можно провести с по­мощью приложения «с полной поддержкой». В этом случае экспериментальная система должна поддерживать все генераторы заданных значений, датчики и интерфейсы исполнитель­ных органов для данной функции.

    Поведение функции в реальном времени также должно быть определено и гарантировано экспери­ментальной системой (рис. «Разработка прототипов с полной поддержкой» ). Вообще, это делается операционной системой реального времени на компьютере с полной поддержкой.

    Виртуальное создание прототипов

    В случае со сложными системами лучше те­стировать функции как можно раньше. Одну из возможностей дает виртуальное создание прототипов. Здесь прототип тестируется в виртуальной модели среды. Операционная система более нового ЭБУ (например, RTA) работает в экспериментальной системе. Это позволяет считать временную характери­стику более нового программного обеспече­ния хорошей.

    Проектирование и реализация программных функций

    На основании спецификации данных на ста­дии проектирования необходимо учесть функциональное поведение программной функции и ее поведение в реальном времени, все технические детали сети ЭБУ, реализо­ванный микроконтроллер и архитектуру про­граммного обеспечения. Тогда окончатель­ная реализация программных функций может быть определена и осуществлена на базе программных компонентов (рис. «Реализация функции управления с обратной связью и без обратной связи с помощью сети ЭБУ» ).

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

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

    Интеграция и тестирование программного обеспечения и ЭБУ

    Требования к программному обеспечению автомобиля

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

    Интеграция компонентов — это точка синхронизации для разработок всех отдельных ком­понентов. Интеграционное, системное и прие­мочное тестирование не могут быть выполнены до тех пор, пока не будут доступны все компо­ненты. Для ЭБУ это означает, что программные функции могут тестироваться только при на­личии всех компонентов в системе автомобиля (ЭБУ, генераторов заданных значений, датчи­ков, исполнительных механизмов и системы). Использование циклических систем тестирова­ния формата In-the-Loop в лаборатории позво­ляет заранее проверять ЭБУ в виртуальной среде тестирования при отсутствии фактиче­ских периферийных компонентов (рис. «Интеграция и тестирование ЭБУ с помощью циклической испытательной системы» ).

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

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

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

    На рис. «Интеграция и тестирование ЭБУ с помощью циклической испытательной системы» ЭБУ изображены в виде «чер­ного ящика». Поведение функций ЭБУ можно оценить только на основе входных и выход­ных сигналов w, у и u * . Этого изображения в виде «черного ящика» достаточно для простых программных функций. Однако для тестирования более сложных функций тре­буется интеграция процедуры измерения для внутренних промежуточных переменных ЭБУ. Эта технология измерения также называется инструментальным методом. Тестирование диагностических функций также требует доступа к запоминающему устройству неис­правностей через диагностический интерфейс ЭБУ, а для этого требуется интеграция измерительно-диагностической системы (рис. «Интеграция и тестирование ЭБУ в реальном автомобиле» ).

    Циклические испытательные системы

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

    • В случае циклических испытаний модели (Model-in-the-Loop, MiL) тестируется функциональная модель программного обеспечения. Модель запускается на ин­струментальном компьютере систем авто­матизированного проектирования.
    • В случае циклических испытаний ПО (Software-in-the-Loop, SiL) тестируется программный код. Он запускается на инструментальном компьютере систем авто­матизированного проектирования.
    • В случае циклических испытаний функции (Function-in-the-Loop, FiL) тестируется про­граммный код. Однако в отличие от SiL, он прогоняется на конечном устройстве. Связь между программным обеспечением и моделью среды выполняется посред­ством ловушек и эмулятора.
    • В случае циклических испытаний аппа­ратной части (Hardware-in-the-Loop, HiL), весь ЭБУ проверяется посредством ин­терфейсов ввода-вывода. Также исполь­зуются сочетания FiL и HiL. В качестве имитационных компьютеров все больше используются персональные компью­теры.

    Циклические испытательные системы могут использоваться для проверки и дальнейшей разработки программного обеспечения и ап­паратной части.

    Калибровка программных функций

    Процедура

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

    Большинство изменений в автомобиле тре­бует изменений в калибровке. Пример, кисло­родный датчик ( λ -зонд в системе запуска из­меряет остаточный кислород в выхлопе. На основе его сигналов можно определить фак­тически впрыскиваемое количество топлива. Таким образом, можно непрерывно и точно адаптировать параметры активации в ЭБУ дви­гателя. Необходимо адаптировать изменения в выпускной системе, приводящие изменению противодавления отработавших газов в точке, где установлен λ -зонд (например, изменен­ный выпускной коллектор, сажевый фильтр). Если этого не сделать, то результатом будет увеличение расхода и вредных выбросов.

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

    Калибровка выполняется в лаборатории на стендах для двигателя и автомобиля во время испытаний автомобиля и в реальных условиях на испытательных маршрутах. В дополнение к измерительно-диагностической системе часто требуется калибровочная система для кали­бровки внутренних параметров ЭБУ, например, характеристических кривых и голограммных карт). По завершении калибровки произво­дится комплексная проверка данных. Затем эти значения записываются в стираемую про­граммируемую постоянную память (EPROM) или флэш-память последовательных ЭБУ.

    Во время калибровки значения параметров должны быть регулируемыми. Поэтому си­стема калибровки состоит из одного или бо­лее ЭБУ с подходящим интерфейсом измерительно-диагностической системы (рис. «Принцип работы измерительно-калибровочных инструментов» ). В дополнение к использованию в автомобилях, измерительно-диагностические и калибровочные системы можно также ис­пользовать в циклических испытательных системах и на испытательных стендах.

    Изменения значений параметров, напри­мер, значений характеристической кривой, поддерживаются в калибровочной системе редакторами. Они также могут работать на уровне реализации (т.е. с примененными зна­чениями) или на уровне физической специ­фикации. Соответственно, измерительная система преобразует записанные значения в физическое представление или представ­ление реализаций. На рис. «Принцип работы измерительно-калибровочных инструментов» показан пример физического уровня и уровня реализации для характеристической кривой и записанного сигнала измерения.

    При работе с системами калибровки обычно можно выбрать либо автономную калибровку, либо калибровку в реальном времени.

    Автономная калибровка

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

    Калибровка в реальном времени

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

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

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

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

    Новые автомобильные функции и технологии будут продолжать увеличивать объем про­граммного обеспечения в автомобилях-даже в бюджетном сегменте. При этом во многих автомобилях количество ЭБУ остается неиз­менным. В результате объем функций некото­рых ЭБУ продолжает расти. В целом систем­ные разграничения между различными ЭБУ исчезают — например, в управлении гибрид­ным приводом. Таким образом, электроника в автомобилях становится все более сложной. Поэтому ключевым элементом будущих раз­работок автомобильного программного обе­спечения и сред разработки станет экономи­ческая составляющая.

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

    Языки программирования и автомобили

    Я тебе сейчас страшную тайну открою, никому не говори! Бортовой комп имеет процессор. Как правило для каждого из процов (семейства) идет своя среда разработки. Разработка ведется на большом брате (WINDOWS, UNIX, MAC), далее скомпилированный код можно загрузить в проц используя программатор. Это если в двух словах.

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

    З.Ы. А еще неплохо бы уточнить, что в твоем понимании

    Список языков программирования по популярности

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

    Интересное из истории

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

    Первый машинный язык был придуман в 1941 году Конрадом Цузе, который является изобретателем аналитической машины. Чуть позже, в 1943 г., Говард Эйкен создал машину «Марк-1», способную считывать инструкцию на уровне машинного кода.

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

    Классификация языков программирования

    На данный момент существует более 300 языков программирования. Каждый из них имеет свои особенности и подходит для одной определенной задачи. Все языки программирования можно условно разделить на несколько групп:

    • Аспектно-ориентированные (основная идея – разделение функциональности для увеличения эффективности программных модулей).
    • Структурные (в основе лежит идея создания иерархической структуры отдельных блоков программы).
    • Логические (в основе лежит теория аппарата математической логики и правил резолюции).
    • Объектно-ориентированные (в таком программировании используются уже не алгоритмы, а объекты, которые принадлежат определенному классу).
    • Мультипарадигмальные (сочетают в себе несколько парадигм, и программист сам решает, каким языком воспользоваться в том или ином случае).
    • Функциональные (в качестве основных элементов выступают функции, которые меняют значение в зависимости от результатов вычислений исходных данных).

    Программирование для начинающих

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

    • Basic придуман в 1964 году, относится к семейству высокоуровневых языков и используется для написания прикладных программ.
    • Python («Питон») довольно легко выучить благодаря простому читаемому синтаксису, преимущество же в том, что на нем можно создавать как обычные десктопные программы, так и веб-приложения.
    • Pascal («Паскаль») – один из древнейших языков (1969 г.), созданных для обучения студентов. Его современная модификация имеет строгую типизацию и структурированность, однако «Паскаль» – вполне логичный язык, который понятен на интуитивном уровне.

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

    Новички имеют возможность ускорить изучение программирования и его основ благодаря специальным инструментам. Основной помощник – это интегрированная среда разработки программ и приложений Visual Basic («Визуал Бейсик» одновременно является и языком программирования, который унаследовал стиль языка Basic 1970-х годов).

    Уровни языков программирования

    Все формализованные языки, предназначенные для создания, описания программ и алгоритмов для решения задач на компьютерах, делятся на две основных категории: языки программирования низкого уровня (список приведен ниже) и высокого уровня. Поговорим о каждом из них отдельно.

    Низкоуровневые языки предназначены для создания машинных команд для процессоров. Главное их преимущество в том, что они используют мнемонические обозначения, т. е. вместо последовательности нулей и единиц (из двоичной системы счисления) компьютер запоминает осмысленное сокращенное слово из английского языка. Самые известные языки низкого уровня – это «Ассемблер» (существует несколько подвидов этого языка, каждый из которых имеет много общего, а отличается лишь набором дополнительных директив и макросов), CIL (доступен в платформе .Net) и Байт-код JAVA.

    Языки программирования высокого уровня: список

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

    Следующий список языков программирования: C («Си»), C# («Си-шарп»), «Фортран», «Паскаль», Java («Ява») — входит в число самых используемых высокоуровневых синтаксисов. Он обладает следующими свойствами: эти языки работают с комплексными структурами, поддерживают строковые типы данных и операции с файлами ввода-вывода информации, а также имеют преимущество – с ними гораздо проще работать благодаря читабельности и понятному синтаксису.

    Самые используемые языки программирования

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

    • языки ООП: Java, C++, Python, PHP, VisualBasic и JavaScript;
    • группа структурных языков: Basic, Fortran и Pascal;
    • мультипарадигмальные: C#, Delphi, Curry и Scala.

    Область применения программ и приложений

    Выбор языка, на котором написана та или иная программа, во многом зависит от области ее применения. Так, например, для работы с самим «железом» компьютера (написания драйверов и поддерживающих программ) лучшим вариантом станет C («Си») или С++, которые входят в основные языки программирования (список смотрите выше). А для разработки мобильных приложений, в том числе игр, следует выбрать Java или С# («Си-шарп»).

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

    Языки программирования и автомобили

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

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

    Трансляторы бывают двух типов — Интерпретаторы и Компиляторы.

    Интерпретатор переводит Вашу программу с языка высокого уровня (например, БЕЙСИКа) в машинный код последовательно строку за строкой. Он работает примерно так: прочитал строку, проверил, нет ли в ней ошибок, перевел ее в машинный код, выполнил команды машинного кода, запомнил, где нужно результат и перешел к следующей строке. Чтобы сделать, например, операцию

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

    Если же Вам позже придется вернуться к этой строке (например, с помощью GO TO 10), то все эти действия будут повторены.

    А ведь многие операции выполняются в циклах.

    Таким образом, интерпретатор работает крайне медленно. Зато имеется возможность работы в диалоговом режиме. Так, на Бейсике, когда Вы набираете программу, каждая строка сразу же и проверяется на правильность синтаксиса и, если Вы сделаете ошибку, то строка не будет введена в программу нажатием клавиши ENTER до тех пор, пока Вы эту ошибку не устраните. Вы всегда можете прервать работу программы, внести изменения и стартовать опять, причем с той строки, с какой хотите. Работать с интерпретатором БЕЙСИКа настолько удобно для начинающих, что на многих моделях персональных ЭВМ, в том числе и на «ZX-Spectrum`е», он уже «зашит» в постоянное запоминающее устройство (ПЗУ) и служит не только языком программирования, но и выполняет функции операционной системы компьютера. При включении компьютера в сеть он сразу готов к выполнению команд БЕЙСИКа.

    В отличие от интерпретатора, компилятор переводит Вашу программу с языка высокого уровня (например, Паскаля или Фортрана) в машинные коды всю целиком. После того, как программа написана, она компилируется в машинный код. Программа, написанная Вами на языке, называется исходным текстом (исходным модулем, исходным блоком, исходным файлом). То, что Вы получаете в результате компиляции, называется объектным кодом (модулем). Вы можете выгрузить объектный код на ленту, а потом снова загрузить. Можете запустить его на исполнение, но здесь у Вас уже нет возможности во время работы программы ее остановить, внести изменения и снова запустить с произвольно взятого места. Если такая необходимость возникает, надо заново загрузить исходный текст программы, внести изменения, а потом опять откомпилировать его в машинный код.

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

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

    Итак, программирование в машинном коде (на Ассемблере) позволяет повысить скорость работы программы по сравнению с работой через интерпретатор в 50…200 раз и в 1,5…3 раза по сравнению с кодом, прошедшим компиляцию. Это бывает чрезвычайно важно, если в программе есть многочисленные вложенные друг в друга циклы, если многократно выполняются поиск и выбор данных из обширных областей памяти. Много времени занимают операции, связанные с обработкой графических изображений на экране. Эффект плавного и быстрого перемещения (и изменения формы) объектов в компьютерных видеоиграх практически всегда создается программированием в машинном коде.

    Второй важный момент состоит в сокращении объема занимаемой памяти. Казалось бы, что 48 килобайтов в «ZX-Spectrum`е» — это немало. Тем не менее, если учесть, что почти 7К занимает экранная область памяти, то при создании красочных программ, содержащих несколько десятков экранов, на их хранение даже и в компрессированном виде уходит несколько десятков килобайт, а надо еще выделить место для хранения таблиц данных, переменных, текстов сообщений и т.п. Поэтому в лучших программах на сам машинный код, по которому они работают, остается всего 4…8К. Здесь и проявляется мастерство программиста, сумевшего обеспечить в столь малом объеме богатое многообразие вариаций игры, палитру цветов и гамму звуков.

    Сравним расход памяти при работе на БЕЙСИКе и в машинных кодах. Программа на БЕЙСИКе размером в 30 строк занимает примерно 1К памяти.

    Аналогичная ей, выполняющая те же задачи, программа в машинных кодах будет иметь примерно 150 строк (команд), но занимают они всего 200…250 байтов оперативной памяти.

    В нашей стране есть еще две объективные причины, вызывающие повышенный интерес к программированию в машинных кодах.

    Дело в том, что наибольшее число пользователей этого класса компьютеров у нас составляют радиолюбители и специалисты по электронике, самостоятельно собравшие компьютер. Обычно они не останавливаются на достигнутом результате. А развивают свое хобби дальше, ищут пути усовершенствования машины, пути подключения дополнительных устройств: интерфейсов принтера, дисковода, джойстика, светового пера, программатора, контроллеров бытовой аппаратуры, бытовых систем, систем управления различными моделями и т.д. Вплоть до систем управления технологическими процессами промышленных предприятий. В конце 80-х годов в Душанбе на базе этого компьютера была сделана система голосования республиканского парламента. Работают под управлением «Спектрума» и очень интересные системы управления сельскохозяйственными предприятиями (фермами и птицефермами). Интересны автоматизированные системы диагностирования автомобиля, системы контроля состояния спортсменов и многое другое. Поскольку процедуры, управляющие работой всех этих устройств (их называют драйверами), обычно пишутся в машинных кодах, то их надо знать и уметь с ними работать.

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

    «ИНФОРКОМ» получает множество писем с вопросами по поводу переделки системы загрузки фирменных программ. Мы так понимаем, что многие уже обзавелись дисководом с Бета-диск интерфейсом, и теперь перед ними стоит задача переписывания программ на диск. При этом пользоваться «магической кнопкой» они не хотят, т.к. при этом любая, даже самая короткая программа будет занимать на диске 48К, а хотят ее переписать на диск блок за блоком и сопроводить загрузчиком с диска. На все эти вопросы ответ может быть только один. Поскольку разные фирмы в своих программах применяют разные системы загрузки, универсального решения здесь не существует. К каждой программе нужен индивидуальный подход. Надо прочитать загрузчик программы, понять куда какой блок загружается и в каком порядке они стартуют, а затем, если надо, внести в него свои изменения. Поскольку лучшие программы имеют при себе загрузчик в машинных кодах (обычно он следует после БЕЙСИК-загрузчика или организован внутри него в строке после оператора REM), то умение работать с машинным кодом Вам пригодится и здесь. Вот в основном те причины, которые могут побудить Вас к освоению программирования в машинных кодах или хотя бы их пониманию (что достигается гораздо быстрее, чем способность активного программирования, но имеет не меньше значения), хотя хотелось бы отметить еще два важных, на наш взгляд, обстоятельства.

    Во-первых, «Спектрум» имеет ПЗУ объемом 16К. Эта память буквально насыщена множеством очень полезных системных процедур. Все они записаны в машинных кодах. Их можно смело применять в собственных программах, обращаясь к ним по мере необходимости. Это дает колоссальный выигрыш в расходе памяти и вообще очень упрощает программирование. Поскольку все содержимое ПЗУ записано в машинном коде, умение разбираться в нем является необходимым. Для использования системных программ, содержащихся в ПЗУ, Вам необходимо ознакомиться с основами программирования в машинных кодах.

    Во-вторых, изучение программирования в машинном коде процессора Z-80 хоть и трудоемкий, но очень полезный шаг для Вашего будущего. Компьютерная техника непрерывно прогрессирует. Широко внедряются IBM-совместимые машины с процессорами 8088, 8086, 80286, 80386, 80486. Процессор Z-80 — «двоюродный брат» процессора 8088 и имеет определенные черты сходства со всей этой серией. Те из Вас, кто свяжут свою судьбу с профессиональной вычислительной техникой, еще не раз вспомнят добром свои первые шаги в освоении машинного кода Z-80.

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

    · Нет необходимости сразу программировать. На первом этапе Вы уже сможете многого достичь, если будете просто разбираться в программах, а дальше все придет с набором опыта.

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

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

    · И, наконец, последнее. Ни один программист, работающий в машинных кодах, не пишет большую программу от начала и до конца с чистого листа. Программа представляет хитроумное сплетение больших и малых подпрограмм (процедур), из которых до 80% стали для этого программиста стандартными, т.е. он применяет их регулярно во всех своих программах без особых перемен, а Вы никогда об этом и не догадаетесь. Это могут быть арифметических и логических вычислений, обработки изображений, опроса внешних устройств (например, джойстика), вывода текста на экран, звуковых эффектов и т.д. и т.п.

    Конечно, если Вы делаете только первые шаги в машинных кодах, то у Вас нет еще такой библиотеки, но прочитав эту книгу, Вы уже можете покопаться в машинном коде некрупных фирменных программ. Там Вы найдете множество открытий. В этом Вам очень поможет какая-либо дисассемблирующая программа, например MONITOR 16/48. Для Вас открыты и другие книги «ИНФОРКОМа» и, самое главное, наши выпуски «ZX-РЕВЮ».

    Языки программирования, разработанные российскими и советскими программистами

    Kotlin (Ко́тлин) — это статически типизированный язык программирования, работающий поверх JVM и разрабатываемый компанией JetBrains. Также компилируется в JavaScript, и в исполняемый код ряда платформ через инфраструктуру LLVM. Язык назван в честь острова Котлин в Финском заливе, на котором расположен город Кронштадт.

    Авторы ставили целью создать язык более лаконичный и типобезопасный, чем Java, и более простой, чем Scala. Следствием упрощения по сравнению со Scala стали также более быстрая компиляция и лучшая поддержка языка в IDE. Язык полностью совместим с Java, что позволяет java-разработчикам постепенно перейти к его использованию; в частности, в Android язык встраивается с помощью Gradle, что позволяет для существующего android-приложения внедрять новые функции на Kotlin без переписывания приложения целиком.

    Компания Google на конференции для разработчиков I/O 2020 объявила, что теперь язык программирования Kotlin будет приоритетным для разработки приложений для операционной системы Android. Все новые API и библиотеки Jetpack будут публиковаться сначала на Kotlin, и только потом на других языках.

    Согласно рейтингу RedMonk Kotlin — самый быстрорастущий язык программирования. Он вошел в топ-20 самых распространённых и «обсуждаемых» разработчиками языков программирования по версии аналитиков компании RedMonk.

    JetBrains (ранее — IntelliJ) — международная компания, которая делает инструменты для разработки на языках Java, Kotlin, C#, C++, Ruby, Python, PHP, JavaScript и многих других, а также средства командной работы.

    JetBrains основана в 2000 году. Головной офис расположен в Праге. Основатели: Сергей Дмитриев, Евгений Беляев и Валентин Кипятков.

    По состоянию на 2020 год у компании шесть офисов — в Праге, Санкт-Петербурге, Бостоне, Москве, Мюнхене и Новосибирске.

    Наиболее известный продукт JetBrains — интегрированная среда разработки IntelliJ IDEA.

    В 2009 году JetBrains открыла код платформы IntelliJ, на которой основана IntelliJ IDEA, и выпустила бесплатную версию IntelliJ IDEA Community Edition.

    С 2010 года компания разрабатывает язык программирования Kotlin. В мае 2020 года компания Google сообщила, что включает поддержку Kotlin в Android Studio 3.0 — официальный инструмент разработки для ОС Android.

    На 2020 год у компании более 5 млн пользователей, среди клиентов: Google, Salesforce, Twitter, Citibank, HP, Airbnb.

    В 2020 году JetBrains впервые стала глобальным спонсором международной студенческой олимпиады по программированию ACM ICPC.

    Встроенный язык программирования 1С:Предприятие

    Встроенный язык программирования 1С:Предприятие — язык программирования, который используется в семействе программ «1С:Предприятие». Данный язык является интерпретируемым языком высокого уровня. Интерпретация текста программного модуля в байт-код выполняется в момент обращения к этому модулю в процессе работы, таким образом обычно интерпретируется только часть текстов программных модулей (в версиях 7.7 и старше). Начиная с версии 8.2 модули компилируются.

    Средой исполнения языка является программная платформа «1С:Предприятие». Визуальная среда разработки («Конфигуратор») является неотъемлемой частью пакета программ «1С:Предприятие».

    Диалекты языка для платформ 1С седьмых версий (7.0, 7.5, 7.7) совместимы «снизу вверх» с незначительными исключениями. Языки для платформ 1С:7.х и 1С:8.х совместимы по основным операторам, но значительно отличаются в работе с прикладными объектами, вследствие чего перенос кода из 1С:7.х в 1С:8.х не имеет смысла.

    Встроенный язык 1С:8 наиболее подобен по своему синтаксису языку Visual Basic.

    Платформой предоставляется фиксированный набор базовых классов, ориентированных на решение типовых задач прикладной области:

    Константа,
    Справочник,
    Документ,
    Журнал документов,
    Перечисление,
    Отчёт,
    Обработка
    План счетов и др.

    На основании базовых классов средствами визуального конфигурирования можно создавать любое количество порождённых классов (возможность определить новый класс программно — отсутствует). Допускается только одна явная ступень наследования классов. Как правило, объекты порождённых классов представляют собой записи (или некоторые наборы записей) в базе данных. Такие классы образуют «Дерево метаданных». В терминах встроенного языка программирования 1С такие классы называются объектами метаданных.

    Основными видами объектов метаданных являются: Справочники, Документы, Отчёты, Обработки, Планы видов характеристик, Планы счетов, Планы видов расчёта, Регистры сведений, Регистры накопления, Регистры расчёта, Бизнес-процессы, Задачи.

    Поддерживаются русский и английский синтаксис команд.

    Проекты на встроенном языке 1С:Предприятия называются конфигурациями. Распространение (продажа) и внедрение таких конфигураций — это основная коммерческая деятельность фирм-партнёров 1С.

    Рабочее название языка — «1Сик» («одинэсик») — очень быстро исчезло из официальных источников. Сейчас при упоминании этого языка в письменных документах нужно писать 1С Язык программирования. Впрочем, часто этот язык называют «встроенный язык», в контексте обсуждения 1С:Предприятия.

    Дружелюбный русский алгоритмический язык, который обеспечивает наглядность (сокр. ДРАКОН) — визуальный алгоритмический язык программирования и моделирования.

    Язык построен за счёт формализации и эргономизации блок-схем алгоритмов, описанных в ГОСТ 19.701-90 и ISO 5807-85.

    Язык может быть использован для разработки программ реального времени.

    Правила языка ДРАКОН по созданию диаграмм разрабатывались с учётом требований эргономики, то есть изначально оптимизированы для восприятия алгоритмов человеком с использованием технологий компьютерной графики. При этом, данный язык рассчитан на создание программ, которые можно было бы просматривать как модели, содержащие код на текстовом языке.

    Возможности языка ДРАКОН могут расширяться в зависимости от нужд пользователя: на языке ДРАКОН можно писать программы для ЭВМ за счет включения в себя функционала и синтаксиса поддерживаемого ИС ДРАКОН или DRAKON Editor текстового языка программирования; при этом программа для ЭВМ, написанная таким образом, считается написанной на гибридном языке ДРАКОН-[название языка].

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

    Программа, считающаяся написанной на «чистом» языке ДРАКОН, является моделью поведения.

    Разработка и использование языка ДРАКОН и его инструментальных средств для ракет-носителей и разгонных блоков космических аппаратов

    Разработка языка ДРАКОН и системы программирования началась в 1986 году. Через 11 лет на базе ДРАКОНа была построена автоматизированная Технология разработки алгоритмов и программ (CASE-технология) под названием «ГРАФИТ-ФЛОКС».

    Затем язык ДРАКОН и система ГРАФИТ-ФЛОКС поступили в эксплуатацию. С их помощью были разработаны многие алгоритмы и программы разгонного блока космических аппаратов ДМ-SL Международного проекта «Морской старт». В общей сложности на разработку и отработку программного обеспечения и других элементов системы управления ушло три года. К 1999 году все работы были закончены. Система была готова к старту.

    Первый пуск ракетного комплекса «Морской старт» состоялся 28 марта 1999 года. Он произошёл в 5 часов 30 минут по московскому времени (27 марта 1999 г. в 18 часов 30 минут по тихоокеанскому времени) со стартовой платформы «Одиссей» в Тихом океане в районе островов Кирибати. Этот пуск был ответственным испытанием языка ДРАКОН и технологии «ГРАФИТ-ФЛОКС». Он продемонстрировал их эффективность и надежность. С тех пор по программе «Морской старт» проведено свыше 30 ракетных пусков.

    Язык ДРАКОН используется и в других космических программах, например: разгонный блок космических аппаратов «Фрегат»; модернизированная ракета-носитель тяжелого класса «Протон-М»; разгонный блок космических аппаратов ДМ-SLБ (проект «Наземный старт»); разгонный блок космических аппаратов ДМ-03; первая ступень южнокорейской ракеты-носителя легкого класса KSLV-1 (Korean Space Launch Vehicle #1); ракета-носитель легкого класса Ангара 1.2; ракета-носитель тяжелого класса Ангара-А5 и др.

    Поскольку результаты использования ДРАКОНа были стабильно высокими, руководство Пилюгинского центра приняло решение об использовании ДРАКОН-технологии в последующих проектах.

    Разработка инструментальных средств языка ДРАКОН для широкого применения

    Распространение языка ДРАКОН можно разделить на два этапа. На начальном этапе информация о ДРАКОНе была недоступна для пользователей, так как работы по ракетно-космическим программам и, в частности, по космической программе Буран были строго засекречены как составляющие государственную тайну. В тот период область применения ДРАКОНа была ограничена ракетно-космической техникой. Язык применялся и применяется в Пилюгинском центре при разработке программ для бортового компьютера «Бисер», установленного на борту ракет-носителей и разгонных блоков космических аппаратов.

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

    Этому способствовал ряд обстоятельств. В открытой литературе стали доступны публикации по языку ДРАКОН. Часть этих материалов появилась в Интернете в конце 2006 года.

    Геннадий Тышов разработал программу «ИС Дракон» (для ОС Windows). Степан Митькин (Норвегия), по своей инициативе (независимо от Пилюгинского центра), разработал программу «DRAKON Editor» (для ОС Windows, Mac, Linux). Программы выложены для свободного скачивания. Пользователи программ получили возможность формировать и использовать визуальные алгоритмы.

    Parser — объектно-ориентированный скриптовый язык программирования, созданный для генерации HTML-страниц на веб-сервере с поддержкой CGI. Разработан Студией Артемия Лебедева и выпущен под лицензией, сходной с GNU GPL. Язык специально спроектирован и оптимизирован для того, чтобы было удобно создавать простые сайты. Работа с формами, cookies, табличными файлами, базами данных и XML — часть языка, а модульность языка позволяет легко наращивать функциональность. Последнее обновление 3.4.5 состоялось 28 апреля 2020 года.

    Parser в известном смысле — макроязык, в котором нет оператора print. Весь текст, набранный в исходном файле, по сути, большой оператор print, а конструкции Parser являются погруженными в текст. Получается, что вы не пишете программу, которая выводит текст — наоборот, в имеющийся текст вы добавляете логику и организацию, блоки (методы), на которые вы разбиваете HTML-код.

    В каждый каталог, с которым будет работать Parser, можно класть файл auto.p, в котором будут описаны основные настройки и методы. Особенностью является наследственность (наличие в нескольких каталогах по пути к скрипту) и безусловное подключение этого файла. Таким образом, вывод меню можно описать лишь в одном файле, и он автоматически будет применен ко всему сайту.

    Некоторые ограничения (например, работа с изображениями) легко устраняются использованием сторонних консольных утилит и shell-скриптов.

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

    *Безопасные толстые указатели на данные и безопасная адресная арифметика — при этом с поддержкой стекового выделения;
    *Высокая степень ABI-совместимости и совместимости на уровне исходных кодов с C, что выливается в возможность вызывать функции скрипта напрямую их хостового C++ приложения, а также копипастить определения C-структур;
    *Реактивное программирование (Excel-подобный пересчёт специально объявленных выражений при изменении правой части);
    *Исключения в виде синтаксического сахара над стандартной моделью кодов ошибок;

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

    Язык «Пифагор» разработан в Красноярском Государственном Техническом Университете в 1995 году, в настоящее время разработка ведется в Институте Космических и Информационных Технологий Сибирского Федерального Университета.

    Название является сокращением фразы «Параллельный Информационно-Функциональный АлГОРитмический» или «Parallel Informational and Functional AlGORithmic».

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

    РЕФАЛ (РЕкурсивных Функций АЛгоритмический) — один из старейших функциональных языков программирования, ориентированный на символьные вычисления: обработку символьных строк (например, алгебраические выкладки); перевод с одного языка (искусственного или естественного) на другой; решение проблем, связанных с искусственным интеллектом. Соединяет в себе математическую простоту с практической направленностью на написание больших и сложных программ.

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

    Первая версия РЕФАЛа была создана в 1966 году Валентином Турчиным в качестве метаязыка для описания семантики других языков. Впоследствии, в результате появления достаточно эффективных реализаций на ЭВМ, он стал находить практическое использование в качестве языка программирования. В настоящее время основными диалектами языка являются РЕФАЛ-2 (1970-е), РЕФАЛ-5 (1985) и РЕФАЛ+ (1990), отличающиеся друг от друга деталями синтаксиса и набором дополнительных средств, расширяющих первоначальный вариант.

    ПРОФТ — язык программирования, разработанный в 2000 году в качества опыта по созданию языка программирования основанного на русском языке.

    Особенностями языка являются использование русского синтаксиса, как средства повышения производительности программирования.

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

    Кроме структурного (процедурного) подхода, в ПРОФТе широко используется возможность выполнения произвольного кода в контексте программы с помощью действия ВыполнитьТекст. Это позволяет широко использовать хранилище кода, избагая таким образом избыточного кодирования.

    До 2006 года ПРОФТ-интерпретатор и Система программирования ПРОФТ 5 были написаны на языке программирования VisualBasic. Из-за низкого быстродействия при обработке большого объема данных было решено полностью переписать интерпретатор на языке Си. Новый интерпретатор создан только с использованием API-функций, без применения сторонних библиотек (таких, например, как MFC). Начиная с лета 2007 года система программирования ПРОФТ 5 была полностью переписана на ПРОФТе.

    «Эль-76» — язык программирования высокого уровня, основанный на использовании русскоязычной лексики и предназначенный для советских многопроцессорных вычислительных комплексов «Эльбрус».

    Его разработка была осуществлена в 1972—1973 годах в Институте точной механики и вычислительной техники АН СССР имени С. А. Лебедева (СССР), изначально он носил название «Автокод Эльбрус», затем ему было дано наименование «Эль-76».

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

    «Эль-76» органически объединяет в себе некоторые низкоуровневые свойства машинного языка, непосредственно контролирующего функции устройств ЭВМ, и ряд высокоуровневых средств во многом аналогичных Алголу-68. Одной из основных особенностей «Эль-76» считалась реализованная возможность хранения в компьютерной памяти информации о типе объявленной переменной вместе с её значением и её изменениями в процессе выполнения кода.

    Участники создания языка: Б. А. Бабаян, В. М. Пентковский, С. В. Семенихин, С. В. Веретенников, В. Ю. Волконский, С. М. Зотов, А. И. Иванов, Ю. С . Румянцев, В. П. Торчигин, М. И. Харитонов, В. С. Шевеков.

    ОСМО — язык программирования высокого уровня, использующий русскую лексику. Разработан в 1980-е годы в СССР. ОСМО сокращение от словосочетания: языковые Средства Общесистемного Математического Обеспечения систем обработки экономической информации (ОСМО СОЭИ). Язык разработан для решения задач систем обработки экономической информации.

    ОВСЕИ — язык программирования высокого уровня, использующий русскую лексику, используемый для записи и решения экономических задач. Разработан в 1980-е годы в СССР. ОВСЕИ сокращение словосочетания язык Описания Вывода Составных Единиц Информации. В этом языке действия ЭВМ задаются переменными (именуются реквизитами), служебными словами и знаками.

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

    ЯМБ — язык программирования, разработанный в конце 1970-х годов в СССР, используемый для бухгалтерских записей, учёта и статистики. Использовался на машинах ЭБМ Искра-554, Искра-555, Искра-2106, Нева-501. ЯМБ — сокращение слов Язык Машин Бухгалтерских.

    Другая версия этого происхождения названия языка ЯМБ — это инициалы руководителя группы его разработки, Ярошевской Марины Борисовны.

    Кроме использования в вышеуказанных машинах язык ЯМБ входил также к комплект поставки IBM PC/XT-совместимой ПЭВМ «Искра 1030.11».

    АЛМИР-65 — язык программирования, разработанный в СССР в 1965 году в Институте кибернетики АН УССР под руководством академика Виктора Глушкова. Название расшифровывается как «алгоритмический язык для машины инженерных решений». Из названия ясно, что АЛМИР-65 использовался на ЭВМ МИР (Машина для Инженерных Расчётов).

    Аналитик — язык программирования, разработан в 1968 г. в Институте кибернетики АН УССР под руководством академика Виктора Михайловича Глушкова. Является развитием языка АЛМИР-65, сохранив с ним совместимость.

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

    Был реализован на машинах МИР-2.

    Позднее была разработана версия Аналитик-74, реализованная на машинах МИР-3.

    На данный момент язык АНАЛИТИК существует в виде системы компьютерной алгебры АНАЛИТИК-2010, которая разрабатывается совместно Институтом проблем математических машин и систем НАН Украины и Полтавским национальным техническим университетом имени Юрия Кондратюка.

    Язык системного программирования (машинно-ориентированный язык), задумывался как язык-посредник при трансляции с различных языков. Идея состояла в том, что для каждой аппаратной платформы достаточно было написать транслятор Алмо — и ты уже можешь работать с множеством языков программирования, которые имели трансляцию в Алмо. Были созданы реализации языка для основных отечественных машин того времени (М-20, БЭСМ-6, Минск 2, Урал 11) и трансляторы с Алгола-60 и ФОРТРАНа в Алмо, причем все трансляторы также были написаны на Алмо и “раскручены” на всех этих машинах.

    «. название языка — Сигма — неожиданно очень удачно стало соответствовать сути разработанного языка, которую можно описать как «Символьный Генератор и Макроассемблер».
    Всего в истории языка Сигма было три его реализации: на М-20, на БЭСМ-б и на самом языке Сигма. Первая, конечно самая памятная, т.к. это была мол первая работа в области системного программирования (да и вообще первая работа). Вторая была выполнена на лучшей, по моему мнению, отечественной машине БЭСМ-6. Третья опиралась на вторую, была раскручена сама через себя и могла генерировать программы как для БЭСМ-6, так и для СМ-4 и ЕС ЭВМ.»

    Центральным звеном проекта БЕТА был Внутренний язык, который должен был стать единым языком-посредником в БЕТА-системе «наибольшим общим делителем» входных языков и «наименьшим общим кратным» выходных машин. Кроме этой своей роли промежуточного языка, позволяющего уменьшить число путей в схеме m -языковой n -машинной трансляции с m * n до m + n , внутренний язык должен был также явиться средой оптимизирующих преобразований, т.е. он ещё должен был быть достаточно богат, чтобы на нем было возможно представить результаты оптимизации; например, экономию совпадающих подвыражений в операторе a [ i , j , k ] := b [ i , j , k ] + c [ i , j , k ].

    В итоге система БЕТА была реализована для языков Симула-67, Паскаль, Модула-2, Ада (подмножество) и выходных машин БЭСМ6 и СМ-4. Был реализован скромный набор оптимизаций — несмотря на обширные замыслы, более скромный, чем в системе Альфа. В общем, сравнительно с Альфа-системой, проект БЕТА следует признать неудачным.

    ЯРМО (Язык Реализации, Машинно-Ориентированный)

    Машинно-ориентированный язык программирования, построенный для ЭВМ БЭСМ-6 и отражающий все тогдашние веяния в информатике. Язык программирования ЯРМО разработан в 1973 году в Новосибирском филиале ИТМиВТ. Впоследствии было разработано несколько версий языка. На нём в 1977 году была создана операционная система «Феликс» для СВС — первая в стране ОС на языке высокого уровня.

    КуМи́р (Комплект Учебных МИРов или Миры Кушниренко) — язык и система программирования, предназначенная для поддержки начальных курсов информатики и программирования в средней и высшей школе. Основана на методике, разработанной во второй половине 1980-х годов под руководством академика А. П. Ершова. Эта методика широко использовалась в средних школах СССР и России. В системе КуМир используется придуманный А. П. Ершовым школьный алгоритмический язык — простой алголоподобный язык с русской лексикой и встроенными командами управления программными исполнителями (Робот, Чертёжник).

    В 1995 году «КуМир» был рекомендован Министерством образования РФ в качестве основного учебного материала по курсу «Основы информатики и вычислительной техники» на основе учебника А. Г. Кушниренко, Г. В. Лебедева и Р. А. Свореня.

    В настоящее время разработана и развивается новая версия КуМира, использующая библиотеку Qt и работающая в операционных системах Linux и Windows. Постановка задачи на разработку новой версии была выполнена А. Г. Кушниренко и А. Г. Леоновым. Разработка ведётся пущинской группой сотрудников НИИСИ РАН под руководством М. А. Ройтберга.

    В 2020 г. в ФГУ ФНЦ Научно-исследовательский институт системных исследований РАН запланировано развитие и поддержка системы КуМир.

    РАПИРА — Расширенный Адаптированный Поплан-Интерпретатор, Редактор, Архив — процедурный язык программирования. Разработан в начале 1980-х годов в СССР в качестве средства перехода от более простых языков (в частности, учебного языка Робик) к языкам высокого уровня. Синтаксис построен на основе русской лексики. Язык использовался в школах для изучения информатики. Преподавание на Рапире велось в «Заочной школе программирования» в журнале «Квант» с начала 1980 года.

    Как видно из расшифровки названия языка, язык РАПИРА изначально был реализован как набор макрорасширений на базе языка ПОПЛАН — интерпретатора языка POP-2. для БЭСМ-6. Некоторые синтаксические конструкции были перенесены из языка Сетл.

    Язык Рапира был реализован для БЭСМ-6, а затем для первой советской ПЭВМ «Агат» в начале 1980-х годов силами нескольких студентов и выпускников Новосибирского государственного университета под началом Г. А. Звенигородского, при участии школьников, в том числе на Всесоюзных летних школах юных программистов (ВЛШЮП, 1982 г.). По своим возможностям язык не уступал другим известным на то время учебным языкам.

    Существовали также реализации языка Рапира для КУВТ УКНЦ и Ямаха КУВТ, а также для ЕС ЭВМ (1982 г., руководитель разработки на алголе-68 — проф. А. Н. Терехов).

    Учебный алгоритмический язык

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

    При изучении информатики в школах для изучения основ алгоритмизации применяется т. н. Русский алгоритмический язык (школьный алгоритмический язык), использующий понятные школьнику слова на русском языке. Алголо-подобный алгоритмический язык с русским синтаксисом был введён в употребление академиком А. П. Ершовым в середине 1980-х годов в качестве основы для «безмашинного» курса информатики. Впервые был опубликован в учебнике «Основы информатики и вычислительной техники» в 1985 г. Язык также применялся для записи алгоритмов в учебнике А. Г. Кушниренко, Г. В. Лебедева и Р. А. Свореня «Основы информатики и вычислительной техники» для 9-10 классов (1990 г. и последующие переиздания; общий тираж составил 7 млн экземпляров).

    Ро́бик — язык программирования, созданный в СССР для обучения основам программирования школьников младших классов (8-11 лет). Язык был разработан в 1975 году, а затем доработан для включения в систему программного обеспечения «Школьница» для компьютера «Агат».

    В языке используется синтаксис, построенный на русской лексике.

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

    Альфа-язык — расширенный диалект языка программирования Algol 60. Разработан в СССР в 1960-х гг под руководством Андрея Петровича Ершова.

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

    АЛГЭК — язык программирования для описания экономических задач. Разработан в 1964 как расширение универсального алгоритмического языка АЛГОЛ-60 средствами языка КОБОЛ. А. имеет аппарат для описания составных единиц информации (документов и их массивов), текстовых величин и процессов их обработки с доступом ко всем элементам. Задание форматов величин позволяет иметь разветвленную систему процедур ввода и вывода. Транслятор с А. разработан для машины «МИНСК-22».

    АЛГЭМ — язык программирования для описания экономических и вычислительных задач, построенный на базе АЛГОЛ-60 и КОБОЛл. Разработан в 1964—66. По сравнению с АЛГОЛ-ом А. содержит дополнительно: строчные (текстовые) переменные и выражения, используемые при операциях над символьной информацией, составные переменные и массивы, позволяющие представлять в машине различные формы экономических документов, указания видов переменных, позволяющие задавать для значений переменных состав и расположения различных типов символов (буквы, цифры и т. д.), что важно для редактирования значений при выдаче на печать. Транслятор с языка А. реализован на ЦВМ «Минск-22».

    «СИРИУС» — система разговорного программирования для решения широкого класса задач, включающих в себя аналитические преобразования в комплексе с обычными вычислениями. Ее составными частями являются одноименные входной язык и транслятор полуинтерпретирующего типа для машин «М-222», однако входной язык и принципы построения системы независимы от конкретной машины. Система разработана в СССР в 1970.

    Предметная область входного языка охватывает большинство объектов матем. анализа: вещественные и комплексные числа, векторы и матрицы с аналитическими компонентами, функции, операторы ∑, П, ∫, lim, max, min и т. п. Входной язык содержит символ «∞», что позволяет естественным образом использовать суммы, интегралы с бесконечными пределами, операторы предельного перехода и т. д. Возникновение ситуаций типа деления на нуль и переполнения разрядной, сетки которые обычно приводят к прерываниям при выполнении программы, в системе «С.» приводят к появлению символа «∞». Система позволяет выполнять следующие преобразования: раскрытие скобок, приведение подобных членов, упрощение аналитических выражений, разложение в ряды, замена переменных и подстановка одних выражений в другие, решение уравнений в буквенном виде, разложение на множители, аналитические операции над матрицами и векторами и т. д.

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

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

    ЯЗЫК МАШИНЫ «МИР»

    ЯЗЫК МАШИНЫ «МИР» — язык программирования, ориентированный на описание алгоритмов решения инженерных и научно-технических задач и включающий средства общения человека с машиной в диалога режиме. Программы на Я. м. «МИР» просты по структуре и хорошо обозримы. Программа состоит из операторной части — последовательности операторов и описательной части — последовательности описаний. Алфавит языка включает в себя заглавные буквы рус. и лат. алфавитов, десятичные цифры, знаки операций (в т. ч. знаки ∑, П, ∫), знаки отношений , скобки, разделители, знаки элементарных ф-ций и служебные слова, взятые из рус. языка. В языке различают два типа данных — целые и десятичные, над которыми определены арифметические операции. Описания типов в языке нет, тип данного определяется по контексту. Отличительной особенностью языка является явное задание в программе указания о разрядности (количества цифр в мантиссе десятичных чисел, которые сохраняются при выполнении операций над числами), с которой должен быть реализован алгоритм. Это соответствует вычисл. возможностям ЭВМ семейства «МИР».

    Еще упомяну несколько языков программирования:

    *Аналитик-74 — язык программирования, использовавшийся на советских ЭВМ серии МИР.

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

    *ЯАП — язык автоматического программирования, использовавшийся на советских ЭВМ Наири и Наири-2.

    *Эпсилон — машинно-ориентированный язык программирования, разработанный в 1967 году в новосибирском академгородке.

    *Jpho — язык программирования стекового типа, реализованный на Java. Не требует компиляции, интегрируется с Java, может интерпретировать разные тексты.;

    Авто это язык программирования?

    AutoIt — это язык программирования? В чем разница между языком программирования и языком сценариев.

    Авто кажется довольно сложным. Есть много вещей, которые вы можете сделать в этом. Код даже может быть скомпилирован в файл .exe. Поэтому я не понимаю, почему это не будет считаться языком программирования.

    5 ответов

    Во многих случаях языки сценариев являются языками программирования. Это, безусловно, выглядит как AutoIt.

    «Сценарии», кажется, применяются в этом случае, потому что они используются для автоматизации взаимодействия с графическим интерфейсом, распространенного использования этого термина.

    Язык сценариев — это язык, который не компилируется, а интерпретируется в режиме реального времени.

    Все языки сценариев являются языками программирования, но не все языки программирования являются языками сценариев.

    Чистый язык сценариев не может существовать сам по себе — он заставляет что-то еще делать что-то (например, JavaScript манипулирует веб-страницами).

    Некоторые языки, такие как Python, Ruby или Perl, называются языками сценариев, потому что они имеют много общего с другими языками сценариев, но их можно использовать отдельно.

    AutoIt звучит как обычный язык сценариев:

    AutoIt v3 — это бесплатный базовый скриптовый язык, разработанный для автоматизации графического интерфейса Windows и общих сценариев.

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

    Однако, как отмечает Грег, важно отметить, что термин «язык сценариев» очень плохо определен, на самом деле ничего не значит и не должен беспокоиться.

    Я ничего не знаю об AutoIt, но чтобы ответить на ваш вопрос о языке программирования или о языке сценариев — Ларри Уолл очень хорошо выразил это в одном из своих адресов State of the Onion:

    Предположим, вы вернулись к Аде Лавлейс и спросили ее, какая разница между сценарием и программой. Она, возможно, посмотрит на вас забавно, а затем скажет что-то вроде: «Ну, сценарий — это то, что вы даете актерам, а программа — то, что вы даете зрителям». Эта Ада была одной острой леди .

    Языки сценариев — это языки программирования, которые используют простой синтаксис (что-то похожее на синтаксис человеческого языка)!

    Синтаксис языков программирования обычно похож на машинный код!

    Итак, поскольку «AutoIt» является языком программирования с простым синтаксисом, он считается языком сценариев!

    Проблема с «AutoIt» заключается в том, что это 100% -ный интерпретируемый язык, следовательно, это также медленный язык!

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

    Интерпретатор «AutoIt» должен переводить «var = var + a_index» в «процессор» 1 миллион раз! (процесс перевода очень медленный!)

    С другой стороны, в скомпилированных языках весь сценарий конвертируется в машинный код, поэтому процессору не требуется «интерпретатор» для выполнения кода, поэтому перевод не требуется! (вышеуказанный цикл может быть в 1 миллион раз быстрее в скомпилированном языке, чем в интерпретируемом!)

    Цукерберг рекомендует:  Java - Разбор кода и постановка задачи
    Понравилась статья? Поделиться с друзьями:
    Все языки программирования для начинающих