Неопытная эксплуатация: электронные СТС за год оформили 4% водителей | Статьи
Электронное свидетельство о регистрации автомобиля за год оформили более 1,6 млн человек — именно столько пользователей на 1 сентября 2022 года зарегистрировались в приложении «Госуслуги Авто», сообщили «Известиям» в Минцифры. За год своей работы сервис получил неоднозначные отзывы. Пользователи жалуются на технические недоработки, а для полноценного запуска необходимы изменения в ПДД, рассказали эксперты. Пока же водители, даже если оформили электронный документ, обязаны возить с собой и его бумажную версию. Тем не менее Минцифры и ГИБДД продолжают внедрять новые технологии — до конца 2022 года в «Госуслуги Авто» появится возможность загружать электронную версию водительских прав, узнали «Известия».
Непопулярное решениеАвтомобилисты России уже год могут оформить себе электронное свидетельство регистрации транспортного средства (СТС). Такая опция доступна в тестовом режиме с 1 сентября 2021 года, и с того момента в приложении «Госуслуги Авто» зарегистрировались более 1,6 млн человек, сообщили «Известиям» в пресс-службе Минцифры.
Документ можно предъявить сотруднику ГИБДД в виде QR-кода, который содержит всю информацию о транспортном средстве. Однако до сих пор с водителей не снята обязанность иметь при себе оригинальный СТС, так как для полноценного запуска электронного документооборота необходимо вносить поправки в ПДД.
Неопытная эксплуатация
Фото: РИА Новости/Алексей Сухоруков
— Правила дорожного движения пункт 2.1.1. — там пока есть только сведения об электронном полисе ОСАГО и больше ни о чем. Ни о свидетельстве о регистрации, ни о водительском удостоверении в цифровом виде. Эти поправки еще предстоит внести, — рассказал «Известиям» президент Коллегии правовой защиты автовладельцев Виктор Травин.
Но пока это невозможно — изменить правила мешает мораторий: в конце 2020 года правительство России приняло постановление, согласно которому ПДД относится к так называемому белому списку нормативных актов, в которые нельзя вносить точечные поправки.
Разрешается только переиздавать весь документ целиком.
— У нас ПДД давным-давно не менялись. В документе до сих пор присутствуют устаревшие понятия, например «временное разрешение на вождение автомобиля». Его отменили еще лет 15 назад. Кроме того, в ПДД есть ссылки на ГОСТы, которые давно упразднены, — подчеркнул эксперт.
Видимо, этим объясняется невысокая популярность новой услуги. Поначалу она вызвала интерес: за первые четыре месяца приложение установили более миллиона пользователей. А за следующие восемь это число увеличилось всего на 600 тыс., следует из данных Минцифры.
— Даже в порядке эксперимента сервис оказался не очень востребованным. У нас до сих пор народ предпочитает иметь бумажные документы. Например, электронные паспорта технического средства (ПТС) можно оформлять с 1 ноября 2020 года, но до сих пор многие мне пишут: «Мы не понимаем, что такое виртуальный ПТС, привыкли к бумажному, и всё». Хотя понятно, что давно надо переходить на электронные документы.
Но за долгие годы нас приучили к бумажкам, — добавил Виктор Травин.
Кроме того, не у всех автовладельцев есть смартфоны и навыки обращения с электронными документами. Эксперт считает, что переход на электронную документацию займет очень много времени.
Неопытная эксплуатация
Фото: ИЗВЕСТИЯ/Алексей Майшев
На момент написания материала рейтинг «Госуслуги Авто» в Google Play составляет 4,0, в App Store — 4,2 и в AppGallery — 4,4. Пользователи отмечают ряд технических проблем с приложением: периодически не подгружаются данные, временами в программе сложно авторизоваться.
«Приложение зависает, долго грузится. С третьего раза загружает фото. Нет возможности добавить страховой полис. Нет уверенности, что приложение включится, когда понадобится показать документы», — написал в комментариях в AppGallery один из пользователей.
Несмотря на то что предъявление СТС доступно без интернета, сам разработчик отметил на комментарий, что QR-код необходимо обновлять, так как «устаревший QR-код вызовет подозрение у сотрудника ГИБДД и повлечет проведение дополнительных проверок».
Тем не менее цифровизация в автомобильной сфере будет продолжаться — уже до конца 2022 года в России могут запустить электронное водительское удостоверение, сообщила «Известиям» пресс-служба Минцифры.
«Сейчас совместно с МВД ведется работа по запуску сервиса предъявления электронного водительского удостоверения в «Госуслуги Авто». В планах обеспечить разработку сервиса до конца года. Функционал предъявления электронного водительского удостоверения будет схож с уже реализованным предъявлением электронного СТС», — подчеркнули в ведомстве.
В пресс-службе добавили, что информация о правах будет загружаться из витрины данных ГИБДД в приложение и генерироваться в виде QR-кода. Сохраненное в приложение водительское удостоверение можно будет показывать без подключения к интернету.
Неопытная эксплуатация
Фото: РИА Новости/Алексей Филиппов
— С правами может получится та же история, — считает майор ГИБДД в отставке Виктор Кондрашин.
Но в целом эксперты положительно относятся к нововведениям ГИБДД и Минцифры.
— Очень поддерживаю этот проект. Если водитель имеет все документы, совершенно неважно, есть они у него с собой или нет, штрафовать его за это не должны. Можно онлайн проверить наличие, убедиться, что они есть. Зачем их возить с собой и рисковать потерять? С водительским удостоверением логично сделать ровно то же самое, — рассказал «Известиям» начальник управления стратегической оптимизации дорожного движения ЦОДД Андрей Мухортиков.
Он подчеркнул, что опыт с ОСАГО доказал, что перевод документов в электронный вид — это удобно и безопасно.
Документы на автомобиль можно предъявить в электронном виде — Газета.Ru
Документы на автомобиль можно предъявить в электронном виде — Газета.Ru | НовостиCNN: начало президентской кампании Трампа играет на руку его главному конкуренту 03:00
СМИ сообщили, что Захарян получит паспорт Армении, но не ради перехода.
Прогноз CNN: республиканцы отобрали у демократов контроль над палатой… 02:53
Глава «Роскосмоса» оценил оборот космической индустрии 02:48
Избранный президент Бразилии призвал ООН отказаться от «логики Второй мировой… 02:35
Роналду рассказал об отношении к критике в свой адрес 02:34
Постпред России Небензя: Запад обращает внимание на заслуги в вывозе российских… 02:26
Илон Маск выбрал своего возможного преемника на посту гендиректора Tesla 02:25
В Минске будут судить мужчину, который убил 15 купленных в интернете котов 02:20
В Молдавии пообещали усилить борьбу с «российскими шпионами» 02:19
close
100%
В России появилась возможность предъявлять инспектору ДПС документы на автомобиль в электронном виде, говорится в рассылке портала «Госуслуги» пользователям.
Для этого Минцифры разработало мобильное приложение «Госуслуги.
Авто» в котором предусмотрена такая функция. Пока она действует в тестовом режиме и работает только со свидетельством о регистрации транспортного средства (СТС), говорится в видеоролике канала «Госуслуги», размещенном на видеохостинге YouTube.
Чтобы воспользоваться этой возможностью, водителю необходимо скачать на смартфон приложение «Госуслуги.Авто». После авторизации пользователя, данные об СТС загрузятся из реестра транспортных средств.
Инспектору ГИБДД для проверки необходимо будет предъявить смартфон с включенным приложением. На экране появится QR-код, который сотрудник ДПС считает с помощью служебного планшета. В видеоролике отмечается, что приложение работает в тестовом режиме и не заменяет традиционный бумажный документ.
Как ранее отмечала официальный представитель МВД Ирина Волк, вопрос о предъявлении автоинспектору водительского удостоверения в электронном виде будет рассматриваться «только в случае успешной реализации мероприятий по использованию электронного свидетельства о регистрации транспортного средства».
Подписывайтесь на «Газету.Ru» в Новостях, Дзен и Telegram.
Чтобы сообщить об ошибке, выделите текст и нажмите Ctrl+Enter
Новости
Дзен
Telegram
Картина дня
«Предложим публичную форму». Зеленский рассказал о готовности к переговорам с Россией
Зеленский заявил, что получал от лидеров государств «сигналы» о готовности РФ к переговорам
«США плевать хотели на расследование». Москва оценила реакцию в НАТО на «ракетный инцидент»
Белый дом заявил, что США возлагают на РФ всю ответственность за ракетный инцидент в Польше
«Все просочилось в газеты. Это неуместно». Как западные лидеры «сливают» переговоры
Глава КНР Си Цзиньпин раскритиковал канадского премьера Трюдо за утечку их разговора в СМИ
Постпред России Небензя обвинил ПВО Украины в систематических попаданиях по жилым домам
Киев сообщил МАГАТЭ об отключении нескольких АЭС от электросетей
Зеленский заявил о создании на Украине «параллельной» системы электроснабжения
«Назовите место и время»: Кадыров отреагировал на объявление его в розыск СБУ
Новости и материалы
СМИ сообщили, что Захарян получит паспорт Армении, но не ради перехода в «Челси»
Прогноз CNN: республиканцы отобрали у демократов контроль над палатой представителей
Глава «Роскосмоса» оценил оборот космической индустрии
Избранный президент Бразилии призвал ООН отказаться от «логики Второй мировой войны»
Роналду рассказал об отношении к критике в свой адрес
Постпред России Небензя: Запад обращает внимание на заслуги в вывозе российских удобрений
Илон Маск выбрал своего возможного преемника на посту гендиректора Tesla
В Минске будут судить мужчину, который убил 15 купленных в интернете котов
В Молдавии пообещали усилить борьбу с «российскими шпионами»
Медведев досрочно лишился шансов на выход в плей-офф Итогового турнира АТР
Каллас заявила об отсутствии прямых угроз Эстонии после инцидента с ракетами в Польше
Глава Минобороны Канады Ананд заявила о выделении Украине военной помощи еще на $25,5 млн
РИА Новости: «Вагнеровцы» применяют «Солнцепеки» для ударов по позициям ВСУ в Артемовске
Российский экооператор призвал СМИ не писать об иностранных экоактивистах-вредителях
На Украине решили конфисковать имущество и активы Януковича
Медведев проиграл Циципасу и потерпел второе поражение на Итоговом турнире АТР
Представитель Польши в ООН: Варшава настроена на поддержку Киева, несмотря на ракетный инцидент
Бывший вице-президент США Пенс усомнился в успехе предвыборной кампании Трампа
Все новости
«Ушла на самоликвидацию».
Откуда прилетела ракета, убившая двух человек в Польше
CNN: Украина признала использование ПВО рядом с местом падения ракеты в Польше
Военная операция РФ на Украине. День 266-й
Онлайн-трансляция военной спецоперации РФ на Украине — 266-й день
«У египтян не в традициях признавать свои ошибки»
Как Египет после революции потерял миллиарды, выбирая между исламистами и туристами
«Киев будет получать вооружения». В НАТО назвали способ добиться переговоров о мире
Генсек НАТО связал исход переговоров по Украине с успехами ВСУ на поле боя
Правда или вымысел: какой получилась драма «Чудо» с Флоренс Пью
Рецензия на загадочную драму «Чудо» с Флоренс Пью
Самые ненадежные автомобили, которые дилеры везут в Россию
Журнал Consumer Reports составил антирейтинг самых ненадежных автомобилей
«Любовные письма музе». Белла Хадид и Эмили Ратаковски – в новом календаре Pirelli
«С вечера не выходила на связь». Что известно об исчезновении замгубернатора Херсонской области
ТАСС сообщило о задержании замглавы Херсонской области Губаревой по «экономическому» делу
«Автомобили должны стать более доступными». Путин попросил не завышать цены
Путин поддержал идею Мантурова распространить льготное автокредитование на военнослужащих
Интервью с Викторией Талышинской — о группе «2 ОКеана» и уходе из «Непары»
Виктория Талышинская ответила на критику бывшего коллеги по группе «Непара» Шоуа
«Назло невзгодам, назло врагам». Москвичи голосованием решат, украшать ли столицу на Новый год
Собянин предложил москвичам проголосовать по вопросу празднования Нового года
«Никогда не нужно спешить с оценками». Песков похвалил США за реакцию на инцидент с ракетой в Польше
Песков отметил сдержанную реакцию США на падение обломков ракеты на востоке Польши
NASA запустило корабль с дрожжами к Луне. Спустя два года туда должны полететь люди
США отправили на Луну сверхтяжелую ракету SLS в рамках миссии «Артемида»
Марина Ярдаева
Хотеть не вредно
О тех, кому достаточно три аршина земли
Юлия Меламед
Журналист глобус пропил
Об экопарк-отелях и русских памятниках в России и Европе
Георгий Бовт
Не догонишь – не похоронишь
О том, как мы хотели перегнать Америку, но потом передумали
Алексей Мухин
Хромая утка по-пекински
О возможном конфликте США и Китая
Мария Дегтерева
Там чудеса, там леший бродит
О бюрократии и чиновничестве в России
—>
Читайте также
Найдена ошибка?
Закрыть
Спасибо за ваше сообщение, мы скоро все поправим.
Продолжить чтение
Как создать четкий высококачественный документ SRS
Любое приложение начинается с идеи, а разработка приложения начинается с документа Спецификации требований к программному обеспечению (SRS). Чем точнее, бизнес-специфичнее и понятнее будет этот документ, тем меньше времени и усилий ваша команда потратит на реализацию идеи. В этой статье мы поделимся проверенными знаниями о том, как эффективно создать документ спецификации требований.
- Когда вам нужен документ SRS
- Что делает спецификацию требований к программному обеспечению хорошей
- Как собрать и унифицировать требования от заинтересованных сторон, пользователей и команды разработчиков
- Как проверить требования перед включением их в спецификацию
- Как убедиться, что спецификация ясна и недвусмысленна
- Примеры хороших и плохих спецификаций
- Заключение
youtube.com/embed/WOt9MTIb7xQ» title=»YouTube video player»> Когда вам нужен документ SRS
Прежде чем перейти к практическим советам, давайте обсудим основную цель создания спецификации требований к программному обеспечению. Это документ, определяющий все необходимые функции для работы приложения. Он фокусируется на пути пользователя и определяет ожидаемый результат. Его необходимо создать, поскольку он способствует лучшему взаимопониманию между заинтересованными сторонами, руководителем проекта и командами проектирования, разработки и тестирования.
Если вы посмотрите на пример документа с требованиями к программному обеспечению, вы найдете руководство по разработке проекта с основными вехами и описанием ожидаемого результата. С ее помощью каждый член команды может быть уверен, что процесс разработки программного обеспечения идет в правильном направлении.
Документ SRS также очень важен для владельца продукта, поскольку он является основным инструментом для создания графика разработки проекта, оценки рисков и определения необходимого времени и бюджета.
Из чего состоит хорошая спецификация требований к программному обеспечению
Если вы просмотрите образцы спецификаций требований к программному обеспечению, вы обнаружите, что все они достаточно четкие, реалистичные и хорошо структурированные. Мы, в CPRIME Studios, используем шаблон SRS, состоящий из следующих разделов:
- Введение
- Предполагаемое использование
- Общее описание
- Цель
- Предполагаемые аудитория
- Особенности системы и требования
- Область
- Определения
- Assplions. и зависимости.
Следующие характеристики также указывают на хорошие требования к программному обеспечению. Они должны быть:
- Явные. Документ SRS должен быть простым для понимания. В нем не должно быть расплывчатых формулировок, чтобы не было недопонимания между заинтересованными сторонами.
- Измеримый. Требования должны быть измеримыми, чтобы можно было проверить и проверить готовый продукт на соответствие требуемым спецификациям.
- Завершено. В документе SRS должно быть достаточно информации, чтобы ваша команда разработчиков могла закончить продукт. С его помощью тестировщики должны проверить, соответствует ли продукт потребностям пользователя и не содержит ли он ошибок.
- Жизнеспособность. Требования должны соответствовать текущей среде, включая бюджет, сроки и технологии. Это не должно зависеть от грядущих технологических прорывов.
- Гибкий. Поскольку рабочая среда может меняться, ваш документ должен быть достаточно гибким, чтобы иметь место для обновлений. Не добавляйте избыточную информацию в несколько разделов, которые необходимо обновлять при каждом изменении.
- Проверяемый. Каждый член команды разработчиков должен иметь доступ к документу, чтобы ссылаться на него так часто, как это необходимо. Требования к программному обеспечению должны быть точными, чтобы членам команды не приходилось запрашивать дополнительную информацию.
- Непротиворечивый. Требования должны согласовываться друг с другом. Весь документ должен быть отформатирован последовательно и использовать одну и ту же терминологию.
- Нет ограничений реализации. Спецификация требований к программному обеспечению должна быть достаточно подробной, чтобы завершить работу. Не делайте его слишком конкретным, потому что это может ограничить разработку или привести к чрезмерным рискам. Разработка во многом зависит от сторонних сервисов, которые разработчики не контролируют.
- Точно. Цели в документе с требованиями к спецификации программного обеспечения должны быть точными, чтобы избежать путаницы. Старайтесь избегать следующего:
- Лазейки: «Приложение должно загрузиться за 3 секунды, если это возможно».
- Неоднозначность: «Продукт MVP должен быть выпущен как можно быстрее».
- Субъективность: «Пользовательский интерфейс должен быть удобным для пользователя».
- Превосходная степень: «Это должно быть лучшее приложение в своем классе».
- Сравнительный анализ: «Это приложение должно быть лучше, чем Slack».
Как собрать и унифицировать требования заинтересованных сторон, пользователей и команды разработчиков
Документ SRS должен способствовать лучшему взаимопониманию между всеми, кто работает над созданием проекта. Он должен соответствовать ожиданиям заинтересованных сторон и предпочтениям пользователей, а также учитывать текущую рыночную и бизнес-среду. Вам необходимо собрать, просмотреть и проанализировать мнения и взгляды каждой вовлеченной стороны, чтобы достичь взаимопонимания. Вы можете использовать следующие подходы для сбора требований для руководства по спецификации требований к системе.
- Индивидуальная проверка. В соответствии с этим подходом каждый член команды может высказать мнение, которое позже будет рассмотрено другими. Например, вы можете создать простой документ с требованиями к программному обеспечению в облачной службе, поделиться им с заинтересованными сторонами и членами команды и предложить им оставить комментарии.
- Формальные методологии. В рамках этой стратегии создание документа SRS можно рассматривать как подпроект с логическим потоком задач. Например, для сбора требований заинтересованных сторон, анализа рынка и т. д.
- Создание примеров дизайна, макетов и каркасов. Этот подход отлично подходит для визуализации будущего решения, а также его можно мгновенно протестировать на приемлемость для пользователей с помощью тепловой карты.
- Мозговой штурм способов повышения эффективности вашего программного обеспечения и указание выигрышных идей в документе с требованиями к программному обеспечению — одна из наиболее эффективных стратегий.
- После согласования требований заинтересованных сторон, пользователей, дизайнеров и разработчиков можно создать прототип будущего решения и еще раз протестировать его с пользователями.
Проверка требований перед их включением в спецификацию
Правильный способ проверки требований спецификации программного обеспечения — проведение бизнес-анализа.
В ходе этого процесса бизнес-аналитик (BA) сможет более глубоко изучить специфику компании, ее текущие потребности, задачи, стоящие перед ней задачи, будущий рынок, на который предполагается выйти софту, а также предпочтения и ожидания целевых пользователей. В случае разработки корпоративного решения вам необходимо выяснить, как решение будет интегрировано с существующими технологиями, и убедиться, что оно будет простым и эффективным для использования сотрудниками.
Кроме того, создание мокапов и прототипов является правильной стратегией предварительного пользовательского приемочного тестирования. Этот подход соответствует лучшим практикам бережливого производства и помогает избежать ошибок на ранних этапах разработки проекта.
Как убедиться, что спецификация ясна и недвусмысленна
Как и в большинстве разговорных языков, английский полон слов, которые имеют несколько определений с тонкими оттенками разных значений. Это здорово, когда дело доходит до самовыражения, но это также может привести к путанице и разногласиям, когда дело доходит до определения и интерпретации SRS.
Таким образом, прежде чем приступить к созданию требований к спецификации программного обеспечения, убедитесь, что заинтересованные стороны и члены группы разработчиков одинаково понимают определенные слова или термины. Особенно важно избегать синонимов. Например, если вы начали использовать термин акции, не используйте акции, иначе может быть неясно, имеете ли вы в виду что-то другое.
Эффективной практикой является проведение отдельной встречи, на которой вы обсуждаете и записываете каждую концепцию, затронутую в документе, и четко объясняете, что они имели в виду, чтобы убедиться, что все согласны друг с другом.
Эксперты также предлагают использовать следующие приемы, чтобы составить как можно более ясный документ с требованиями к программному обеспечению:
- Используйте активное время. Проще говоря, избегайте пассивного залога при построении предложений в документе SRS и следуйте четкой структуре, состоящей из подлежащего, сказуемого и необходимых дополнений. Постарайтесь максимально сократить и упростить последний.
- Не путайте требования. Здесь действует правило написания эссе в колледже. Каждый абзац должен содержать только одну ключевую мысль вашего эссе. Что касается спецификаций, один абзац = одно требование.
- Укажите и определите терминологию, которую вы используете, и не придумывайте новые термины и не заменяйте их.
Постарайтесь максимально сократить и упростить последний.Примеры хороших и плохих спецификаций
Чтобы получить четкое представление о том, как правильно писать требования к программному обеспечению, сравните следующие примеры хороших и плохих спецификаций требований к программному обеспечению. Ниже указано, что ваша спецификация требований должна и не должна содержать.
Заключение
Cprime Studios имеет более чем 20-летний практический опыт разработки программного обеспечения. В компании работают технически подкованные бизнес-аналитики и менеджеры проектов, которые готовы помочь вам собрать ваши требования и проверить ваши идеи.
Наша команда разработчиков будет рада создать ваше решение в соответствии с указанными вами требованиями, чтобы вы могли получить качественный продукт, повышающий ценность вашего бизнеса!
Отчет о требованиях к программному обеспечению для автономных автомобилей – AutoCar Project
Содержание
- 1. Введение
- 1.1. Назначение
- 1.2. Предполагаемая аудитория и рекомендации по прочтению
- 1.3. Объем проекта
- 1.4. Определения, акронимы и сокращения (Глоссарий/Терминология)
- 1.5 Каталожные номера
- 2. Общее описание
- 2.1. Перспектива продукта
- 2.2. Функции продукта
- 2.3. Классы пользователей и характеристики
- 2.4. Операционная среда
- 2.5. Ограничения
- 2.6. Допущения и зависимости
- 2.6.1. Допущения
- 3. Спецификация требований
- 3.1. Требования к внешнему интерфейсу
- 3. 1.1. Пользовательские интерфейсы
- 3.1.2. Аппаратные интерфейсы
- 3.1.3. Программные интерфейсы
- 3.1.4. Коммуникационные интерфейсы
- 3.
- 3.2. Функциональные требования
- 3.2.1. Варианты использования
- 3.3. Нефункциональные требования
- 3.3.1. Требования к производительности
- 3.3.2. Требования безопасности
- 3.3.3. Требования безопасности
- 3.3.4. Атрибуты качества программного обеспечения
- 3.3.5. Бизнес-правила
- 3.1. Требования к внешнему интерфейсу
- 4. РЕФЕРЕНЦИИ
1.1. Пользовательские интерфейсы Автономные транспортные средства — это автомобили, которые могут двигаться без какого-либо вмешательства, определяя дорогу, транспортный поток и окружающие объекты с помощью имеющейся у них системы управления. Эти автомобили могут обнаруживать объекты вокруг себя с помощью таких технологий и методов, как RADAR, LIDAR, GPS, одометрия, компьютерное зрение. Привод автопилота автономных транспортных средств на короткое время начинается с ультразвуковых датчиков на колесах, определяющих положение транспортных средств, которые тормозят или припаркованы, а данные от широкого спектра датчиков анализируются с помощью центральной компьютерной системы и событий, таких как рулевое управление, торможение и разгон выполняются.
Это событие можно назвать только началом. По мере того, как компьютерные технологии становятся доступнее и дешевле, будущее беспилотных автомобилей становится все более достижимым. Несмотря на то, что все еще находится в зачаточном состоянии, технология беспилотного вождения становится все более распространенной и может радикально изменить нашу транспортную систему (и, соответственно, нашу экономику и общество).
1.1. Цель
Мы стремились добавить в автономные автомобили функцию определения приоритета автомобиля экстренной помощи. В нашем проекте мы планируем использовать искусственный интеллект, машинное обучение, методы обработки изображений и тестировать результаты в среде моделирования. Симулятор автономного вождения автомобиля, который мы будем использовать, должен предоставить нам возможность моделировать датчики, такие как LIDAR, GPS, радар, и давать потенциальные выходные данные датчиков, с этими выходными данными и путем опробования возможных сценариев движения мы улучшим программное обеспечение, которое мы будем делать.
При приближении машины скорой помощи с помощью аудиодатчиков автомобиль распознает сирену, а с помощью датчика света проверит, находится ли машина скорой помощи позади автомобиля, а не на противоположной стороне дороги, затем переключится на свободную линию, чтобы очистите путь автомобиля скорой помощи. Эта функция не только опустошает на основе правила одной полосы движения, потому что машина скорой помощи может подъехать с левой полосы, попытаться сделать аварийный коридор или может использовать обочину дороги.
1.2. Предполагаемая аудитория и рекомендации по прочтению
Этот отчет о спецификации требований к программному обеспечению предназначен для разработчиков программного обеспечения, архитекторов программного обеспечения, тестировщиков, менеджеров проектов и составителей документации. Прежде чем читать этот отчет, прочтите наш обзор литературы, который может помочь понять принципы работы датчиков и алгоритмов. Этот отчет включает общее описание продукта и спецификацию требований проекта.
1.3. Объем проекта
В этом проекте мы стремились добавить в автономные автомобили функцию определения приоритета аварийного транспорта. Автономный автомобиль, который мы моделируем, сможет обнаруживать машины экстренных служб, а также их местоположение и направление. Автономный автомобиль будет использовать визуальную информацию; поэтому на транспортном средстве необходимо установить несколько камер.
Наша система будет включать в себя:
- Обнаружение полосы движения и отслеживание
- Распознавание объектов и автоматическое торможение
- Виртуальный помощник вождения
- Планирование маршрута
- Оповещение о приоритете аварийного транспортного средства
первые четыре из этих автономных автомобилей уже имеют первые четыре из этих функций . Мы добавим пятую в качестве новой функции для автономных автомобилей.
Чтобы добиться успеха в этом проекте, нашему автомобилю как минимум нужно следовать по полосе, не задевать объекты на дороге и пропускать машину скорой помощи, меняя полосу движения.
Другие функции могут меняться в зависимости от возможностей симулятора.
1.4. Определения, акронимы и сокращения (Глоссарий/Терминология)
| Терминология | Определение |
|---|---|
| Пользователь | Лицо, взаимодействующее с системой. |
| SRS | Отчет, содержащий обзор всех компонентов системы. |
| Автономное вождение | Режим управления, при котором транспортное средство не требует внимания водителя. |
| Аварийный автомобиль | Аварийный автомобиль — это любой автомобиль, предназначенный и уполномоченный для оказания экстренной помощи в опасной для жизни ситуации [1]. |
| Приоритет транспортного средства | Когда приближается транспортное средство с более высоким приоритетом, все другие транспортные средства должны остановиться или двигаться с правой стороны, чтобы пропустить транспортные средства. |
| Система | Системное программное обеспечение — это тип компьютерной программы, предназначенный для запуска аппаратного обеспечения компьютера и прикладных программ [2]. |
| Блок управления | Блок управления (ЦУ) — это компонент центрального процессора (ЦП) компьютера, который управляет работой процессора [3]. |
1.5 Ссылки
- Этот документ написан на языке Markdown со вкусом GitHub.
- IEEE Std 830™-1998(R2009) Рекомендуемая практика для спецификаций требований к программному обеспечению.
В этом разделе объясняются аспекты системы самоуправляемых автомобилей и требования.
2.1. Product Perspective
Самостоятельное вождение: Системы классификации, которые контролируют дорожные знаки, используют камеры, контролируют другие системы, используют радарные и лазерные датчики.
ЛИДАР: Технология оптического дистанционного зондирования для измерения расстояния до цели путем освещения.
GPS: Космическая спутниковая навигационная система, предоставляющая информацию о времени и местоположении в любом месте.
Цифровые карты: Процесс, в котором сбор данных компилируется и форматируется в виртуальном образе.
Адаптивный круиз-контроль: Отслеживает расстояние до соседних транспортных средств на той же полосе. Обнаруживает объекты перед транспортным средством с риском аварийного столкновения.
Lane Assist: Отслеживает положение автомобиля на полосе.
Датчики звука и света: Это система, которая будет использоваться специально для идентификации автомобилей с приоритетом. Он также будет использоваться для обнаружения окружающих объектов, дорожек и других инструментов.
2.2. Функции продукта
Обнаружение полос движения: Система обнаруживает линии движения на шоссе. Различает пунктирные и прямые линии. Предупреждает в случае потери полосы движения. Методы анализа изображения используются для определения линий.
Среда отслеживания: Отслеживает объекты вокруг автомобиля с помощью сканера и алгоритмов.
Датчики отслеживают положение объектов по мере их перемещения в пределах диапазона сканирования. Итак, система ведет себя в соответствии с объектами.
Обнаружение дорожных знаков: Используя методы обработки изображений и различные алгоритмы, проводятся исследования для классификации дорожных знаков. Распознавать дорожные знаки. Транспортное средство ведет себя в соответствии с цветами светофора.
Обнаружение и отслеживание транспортных средств: Система выполняет обнаружение и отслеживание транспортных средств. Он регулирует скорость и положение в соответствии с поведением транспортных средств вокруг него во время движения по шоссе. Внезапное торможение выполняет такие действия, как смена полосы движения. Сохраняет дистанцию пути всегда постоянной с транспортным средством впереди.
Применить торможение: Если перед автомобилем наступает пешеход и возможно столкновение, было выполнено резкое торможение.
Когда препятствия, пешеходы и транспортные средства на дороге убираются, автомобиль ускоряется, чтобы восстановить свою скорость.
Планирование дорог: Целью этого проекта является создание планировщика дорог, который может прокладывать безопасные траектории движения транспортного средства. На шоссе есть другие машины, все с разной скоростью. Автомобиль передает свое положение вместе с данными датчиков, которые оценивают положение всех транспортных средств на одной и той же стороне дороги.
Право приоритета транспортных средств: Распознает транспортные средства, такие как пожарные машины или машины скорой помощи, с помощью звуковых датчиков и методов обработки изображений. Система меняет полосу движения, чтобы уступить дорогу этим автомобилям.
2.3. Классы и характеристики пользователей
В этом разделе рассматриваются все характеристики и ожидания пользователей, относящиеся к пользователю системы. Пользователь в контексте этого проекта будет считаться работающим при определенных предположениях.
Эти предположения включают в себя то, что пользователь может взаимодействовать с системой посредством управления автомобилем, а также с помощью визуального освещения или звукового предупреждения. В случае конфликта с другими системами автомобиля пользователь имеет право отключить систему.
Транспортные средства, которые будут оснащены системой, используемой в нашем проекте, будут автономными. Поэтому ожидается, что взаимодействие пользователя с системой будет минимальным. Мы предполагаем, что пользователь мало или вообще ничего не знает о системе.
2.4. Операционная среда
Используемые аппаратные средства, программное обеспечение и технологии должны иметь следующие характеристики:
- Процессор с частотой 2 ГГц
- Непрерывное электропитание
- Возможность использования камеры, микрофона и других сервисов системы
- 1 ГБ памяти или больше
Разрабатываемое программное обеспечение будет тестироваться на Webots, который является кросс-платформенным симулятором с открытым исходным кодом.
2.5. Ограничения
В этом разделе рассматриваются ограничения системы, а также описания критически важных для безопасности свойств системы.
Система предназначена для помощи пользователю в управлении транспортным средством, и система всегда должна работать правильно. Бывают ситуации, когда система требует сдержанности. При отсутствии дорожной разметки (немаркированная полоса, грунтовая дорога, плохая погода и т. д.) система становится неэффективной и должна выдавать пользователю звуковое или визуальное предупреждение. Это будет продолжаться до тех пор, пока не будут достигнуты дорожные условия с четкой разметкой полос движения.
Если есть проблема с камерами, используемыми для обнаружения этих полос, система снова не будет работать. Также это может быть неисправность камер и звуковых датчиков, которые видят приоритетные автомобили. В этом случае система снова выключается и должна снова отображать предупреждение для пользователя. Эта проблема актуальна до тех пор, пока камера или звуковые датчики не будут отремонтированы.
Датчики по-прежнему будут использоваться для получения информации о расстоянии. Данные датчика будут использоваться с камерой для объектов вокруг автомобиля. Требуется стабильное и быстрое подключение к Интернету при поиске объектов вокруг. В противном случае он не сможет быстро взаимодействовать с другими инструментами.
Система должна быть настроена для ответа на команды через 500 мс. Если во время движения на дороге появляется препятствие, время срабатывания и время отпускания тормоза всегда должны быть одинаковыми, чтобы достичь желаемого замедления. Во всех сценариях скорость автомобиля должна быть постоянной.
2.6. Предположения и зависимости
При создании проекта использовались различные предположения и зависимости, чтобы обеспечить безопасную и эффективную работу системы.
2.6.1. Предположения
- Основным предположением в этом проекте является то, что система работает хорошо, когда нет факторов окружающей среды. (Плохая погода, ямы, уклон и т. д.)
- Предполагается, что дорожная разметка различима.
- В нашей системе предполагается, что все дорожные знаки и наличие всех объектов вокруг транспортного средства могут быть четко видны.
- Приоритетные транспортные средства, такие как машины скорой помощи и пожарные машины, четко распознаются по голосу и распознаванию изображений.
- Если автомобиль работает, предполагается, что система всегда включена и сканируется.
- Предполагается, что все элементы системы работают исправно и ненормальных состояний нет.
д.) Этот раздел содержит требования к созданию нашей программной системы и описание ее поведения.
3.1. Требования к внешнему интерфейсу
Информация, представленная в этом разделе, обеспечивает правильную связь системы с внешними компонентами.
3.1.1. Пользовательские интерфейсы
Пользователь может запускать и выключать систему. И может видеть информацию об автомобиле на приборной панели, такую как спидометр, тахометр, одометр, датчик температуры охлаждающей жидкости двигателя и указатель уровня топлива, указатели поворота, индикатор положения переключения передач, сигнальная лампа ремня безопасности, сигнальная лампа стояночного тормоза и индикаторы неисправности двигателя.
И может отдавать команды типа «скорость до 70 км/ч», «перестроиться в левую полосу» с виртуальной помощью.
3.1.2. Аппаратные интерфейсы
Аппаратный интерфейс может включать в себя датчики и обязательно блок управления (например, DRIVE AGX Kit), но пока мы пытаемся сделать и протестировать все в среде моделирования, поэтому не будет использоваться какое-либо внешнее оборудование, кроме наших компьютеров.
3.1.3. Программные интерфейсы
Поскольку это среда моделирования, нет требований к внешнему программному интерфейсу. Но если мы сможем построить прототип, программные интерфейсы изменятся в зависимости от аппаратного обеспечения, которое мы будем использовать.
3.1.4. Коммуникационные интерфейсы
Требования к внешнему коммуникационному интерфейсу отсутствуют.
3.2. Функциональные требования
Эта часть отчета включает функциональные требования проекта.
3.2.1. Варианты использования
Рис.
1. Диаграмма вариантов использования нашего проекта.| Вариант использования Название | Описание |
|---|---|
| Запуск системы | Пользователь включает систему. |
| Отдать голосовой приказ | Пользователь отдает основные приказы системе с помощью голоса. |
| Планирование маршрута | Система получает от пользователя введенное местоположение, проверяет его существование, находит кратчайший путь к нему. |
| Изменить маршрут | Изменяет место ввода или отменяет его. |
| Управление расстоянием | Проверяет окружение транспортных средств и находит приблизительное расстояние до объектов. |
| Автоматический тормоз | Останавливает автомобиль, когда перед автомобилем появляется объект. |
| Управление полосой движения | Управляет транспортным средством, чтобы оставаться в центре полосы или изменять базовую полосу в соответствии с предупреждением о приоритетном транспортном средстве или запросом пользователя. |
| Круиз-контроль | Управляет ускорением. Замедляет, ускоряет или фиксирует ускорение автомобиля. |
| Оповещение о приоритетном транспортном средстве | Отображает оповещение на приборной панели и предпринимает необходимые действия при приближении или удалении аварийного автомобиля. |
| Сплошной красный | Светофор перед автомобилем горит красным светом. |
| Непрерывно желтый | Светофор перед автомобилем горит непрерывным желтым светом. |
| Сплошной зеленый | Светофор перед автомобилем горит зеленым цветом. |
| Мигающий красный | Светофор перед автомобилем мигает красным светом. |
| Мигающий желтый | На светофоре перед автомобилем мигает желтый свет. |
| Необычный светофор | Неправильно работает сигнал светофора перед автомобилем (не горят фары, горят все фары и т. д.). |
| Дорожные знаки | Когда перед автомобилем стоит дорожный знак. |
| Останов системы | Пользователь выключает систему. |
3.2.1.1. Сценарий: Запустить Систему
Описание
Пользователь включает систему, чтобы использовать автомобиль.
Функциональный ответ
Система включит датчики и проверит другие компоненты. Ожидает ввода пункта назначения.
3.2.1.2. Сценарий: голосовой приказ
Описание
Пользователь может отдавать голосовые приказы об изменении пункта назначения или ускорения.
Функциональный ответ
С помощью виртуального помощника системы система получит заказ и на его основе будет активирован модуль круиз-контроля или модуль управления полосой движения или модуль изменения маршрута.
3.2.1.3. Сценарий: планирование маршрута
Описание
Система получает данные о пункте назначения от пользователя.
Функциональный ответ
Система получает ввод назначения. Если не удается найти пункт назначения в базе данных GPS или дорожной сети, отображается сообщение об ошибке. В противном случае он вычисляет кратчайший путь к месту назначения и показывает маршрут.
3.2.1.4. Сценарий: изменение маршрута
Описание
Пользователь может изменить маршрут с помощью голосового приказа или отменить его.
Функциональный ответ
Голосовой приказ будет распознан виртуальным помощником системы. На основе заказа пользователя будет рассчитан новый кратчайший путь, или транспортное средство будет припарковано на обочине шоссе или на стоянках до поступления нового заказа.
3.2.1.5. Сценарий: управление расстоянием
Описание
Проверяет окружение автомобиля и находит приблизительное расстояние до объектов с помощью данных, поступающих с камер и LIDAR.
Функциональный ответ
Данные компьютерного зрения отправляются в модель машинного обучения для классификации. Модель классифицирует выбранную область окружающей среды, является ли она чистой или нет. И пытается сбалансировать расстояние между объектами и транспортным средством.
3.2.1.6. Сценарий: автоматический тормоз
Описание
Останавливает автомобиль, когда перед ним появляется объект.
Функциональный ответ
Когда объект внезапно появляется перед автомобилем, система автоматически останавливает автомобиль. Автомобиль остается неподвижным, пока существует препятствие. После очистки он продолжает свой путь.
3.2.1.7. Сценарий: Управление полосами
Описание
Управляет операциями полос.
Функциональный ответ
В полосе он уравновешивает автомобиль, чтобы оставаться в центре полосы с данными компьютерного зрения, поступающими с камер.
Если есть запрос от пользователя на изменение линии, он использует дистанционное управление для проверки среды и изменяет строку на основе запроса.
3.2.1.8. Сценарий: Круиз-контроль
Описание
Управляет скоростью двигателя.
Функциональный ответ
Изменяет скорость двигателя в зависимости от команды пользователя или от модуля дистанционного управления.
3.2.1.9. Сценарий: Предупреждение о приоритетном транспортном средстве
Описание
Отображает оповещение на приборной панели и предпринимает необходимые действия при приближении или удалении автомобиля экстренной помощи.
Функциональный ответ
При приближении машины скорой помощи с помощью аудиодатчиков автомобиль распознает сирену, а с помощью камер и датчиков проверяет, находится ли машина скорой помощи позади автомобиля, а не на противоположной стороне дороги, затем переключается на свободную линию, чтобы очистите путь автомобиля скорой помощи.
Этот модуль не только опорожняет на основе правила одной полосы движения, потому что машина скорой помощи может подъехать с левой полосы, попытаться сделать аварийный коридор или может использовать обочину дороги.
3.2.1.10. Сценарий: сплошной красный
Описание
Когда перед автомобилем горит красный свет светофора. Это означает остановить машину.
Функциональный ответ
Автомобиль замедлится и остановится до следующего сигнала от компьютерного зрения.
3.2.1.11. Сценарий: Непрерывно желтый
Описание
Когда перед автомобилем горит непрерывный желтый сигнал светофора. Это значит приготовиться.
Функциональный ответ
Автомобиль будет замедляться до тех пор, пока не появится следующий ввод. Если он горит красным, то будет включен вариант использования, если он горит зеленым, будет включен вариант использования.
3.2.1.12. Сценарий: сплошной зеленый
Описание
Когда перед автомобилем горит желтый сигнал светофора. Это значит идти.
Функциональный ответ
Автомобиль ускоряется прямо, если на дороге нет препятствий.
3.2.1.13. Сценарий: мигающий красный
Описание
Когда перед автомобилем стоит светофор с мигающим красным светом. Это означает то же, что и знак стоп. После остановки продолжайте движение, когда это безопасно, и соблюдайте правила проезда.
Функциональный ответ
Автомобиль замедлится и остановится до следующего сигнала от компьютерного зрения.
3.2.1.14. Сценарий: мигающий желтый
Описание
Когда перед автомобилем стоит светофор с мигающим желтым светом. Он предупреждает вас об осторожности. Сбавьте скорость и будьте особенно бдительны.
Функциональный ответ
Транспортное средство замедлится и после проверки окружающей среды с помощью системы управления расстоянием. Машина продолжит свой путь.
3.2.1.15. Сценарий: Необычный светофор
Описание
Когда перед автомобилем стоит светофор без включенных огней или горит более одного светофора.
Функциональный ответ
Транспортное средство замедлится и после проверки окружающей среды с помощью системы управления расстоянием. Машина продолжит свой путь.
3.2.1.16. Сценарий: Дорожные знаки
Описание
Когда перед автомобилем стоит дорожный знак.
Функциональный ответ
Данные компьютерного зрения отправляются в модель машинного обучения для классификации. Модель классифицирует признак и действует на его основе.
3.2.1.18.
Сценарий: Stop System
Описание
Выключает систему.
Функциональный ответ
Когда пользователь хочет выключить систему, автомобиль автоматически паркуется в безопасной зоне и останавливает систему.
3.3. Нефункциональные требования
Эта часть включает нефункциональные требования проекта.
3.3.1. Требования к производительности
| Требование к производительности | Описание |
|---|---|
| Время отклика | Эта система работает в режиме реального времени. Итак, время отклика (T_response=T_actuation-T_event) должно быть 500 мс. |
| Обработка ошибок | При возникновении непредвиденного сбоя системе необходимо кратковременно восстановиться. |
| Рабочая нагрузка | Система должна быть в состоянии обрабатывать множество входных данных из окружающей среды в различных сложных погодных условиях и условиях движения. |
| Масштабируемость | Датчики и другие бывшие в употреблении аппаратные средства эффективны, но мы работаем над моделированием, масштабируемость не требуется. |
3.3.2. Требования безопасности
| Требования безопасности | Описание |
|---|---|
| Защита от вреда | Автономная автомобильная система должна предотвращать аварии и не должна травмировать пассажиров. |
| Защита от опасностей | Автономная автомобильная система не должна начинать движение, когда ее двери еще открыты. И уведомлять пользователя, когда ремень безопасности не пристегнут. |
| Идентификация ошибок безопасности | Автомобиль должен идентифицировать системные ошибки. |
| Отчет об ошибках безопасности | Система должна уведомлять пользователя об опасной ситуации и позволять пользователю взять на себя управление транспортным средством, когда система работает неправильно. |
| Этические соображения | Система должна принимать этические решения в экстренных случаях. |
| Обнаружение и реагирование | Транспортное средство должно соблюдать правила дорожного движения, обнаруживать объекты в своем окружении и реагировать на них. |
3.3.3. Требования безопасности
- Система должна защищать датчики от внешних и внутренних угроз.
- Алгоритмы этих датчиков должны быть защищены.
