-Поиск по дневнику

Поиск сообщений в predefglas

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 10.12.2014
Записей:
Комментариев:
Написано: 94

Функциональная безопасность, Часть 2 из 2. МЭК 61508: кем быть, Шерлоком Холмсом или Дата Туташхиа?

Дневник

Суббота, 10 Сентября 2016 г. 00:14 + в цитатник
источник#1; источник#2 Безопасности на хабре посвящен целый хаб, и, пожалуй, никто особенно не задумывается, что именно вкладывается в понятие «безопасность», и так все ясно: информационная безопасность (security). Однако, есть еще и другая сторона безопасности, safety, связанная с рисками для здоровья и жизни людей, а также окружающей среды. Поскольку информационные технологии сами по себе опасности не представляют, то обычно говорят о функциональной составляющей, то есть о безопасности, связанной с правильным функционированием компьютерной системы. Если информационная безопасность стала критична с появлением интернета, то функциональная безопасность рассматривалась и до появления цифрового управления, ведь аварии происходили всегда. Данная статья продолжает серию публикаций на тему функциональной безопасности. Во вводной части 1: — обоснована важность оценивания и обеспечения функциональной безопасности для компьютерных систем управления; — рассмотрены архитектуры систем, для которых необходимо оценивать и обеспечивать функциональную безопасность; к таким системам относятся АСУ ТП (Industrial Control Systems) на базе программируемых логических контроллеров (ПЛК), встроенные системы (Embedded Systems) и уровень устройств (Device Layer) для интернета вещей; — кратко представлено множество стандартов, относящихся к функциональной безопасности в различных сферах применения. Для того чтобы сделать еще один шаг, необходимо продолжить рассмотрение стандарта МЭК 61508 «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью» (IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems). Дело в том, что функциональная безопасность – это достаточно формализованное свойство, поскольку системы, важные для безопасности, являются предметом государственного лицензирования во всех странах. Изучение стандартов и заложенной в них терминологии – это не самое веселое занятие в мире, но, при прагматичном подходе, технический уровень специалиста может от этого повыситься. Толкование терминологии является своего рода «технической юриспруденцией», а хитросплетению сюжетных линий в изложении требований может позавидовать любой автор детектива. Я не стану уверять, что, изучая стандарты, все сразу станут техническими Шерлоками Холмсами. Хотя, знание основ стандартизации (то есть, технического законодательства), лежит в основе работы любого сыщика технического эксперта. Изучение стандартов – это скорее путь Дата Туташхиа из полузабытого ныне романа Чабуа Амирэджиби (а есть еще экранизация – «Берега»), путь не столько вперед, сколько в глубину, не столько в действие, сколько в осмысление. Общие сведения о МЭК 61508 Стандарт оперирует термином электрическая/ электронная/ программируемая электронная (Э/Э/ПЭ) система (electrical/electronic/programmable electronic). Особенностью стандарта является риск-ориентированный подход. В зависимости от риска, который техногенный объект создает для окружающей среды, жизни и здоровья людей, устанавливаются риски для отказов систем управления. Например, обратим внимание на системы защиты атомных реакторов. Для них в режиме постоянной работы отказы должны происходить не чаще, чем один раз в 1000 лет эксплуатации (10 миллионов часов наработки на отказ). Такие показатели задаются не для единичного объекта, а для «флота», т.е. для множества однотипных объектов. Вроде бы, отказы являются достаточно редкими событиями, ведь ни одна атомная электростанция не проработает тысячу лет. Однако, если учесть, что в мире эксплуатируется более 400 атомных реакторов, то для «флота» мы уже получим цифру один отказ в 2,5 года, что звучит гораздо более удручающе. Во время Чернобыльской и Фукусимской ядерных катастроф системы аварийной защиты не сработали так, как ожидалось проектировщиками. Это еще один аргумент в пользу важности рассмотрения функциональной безопасности. Для снижения значений рисков ниже заданных показателей реализуется комплекс организационно-технических мер, которые также регламентированы в МЭК 61508, в зависимости от допустимой величины риска отказа. Кроме того, МЭК 61508 представляет собой верхний уровень целого семейства отраслевых стандартов, которые детализируют требования к функциональной безопасности для систем управления медицинским оборудованием, автомобильным и железнодорожного транспортом, АСУ ТП и т.д. Первая редакция МЭК 61508 была разработана с 1998 по 2000 годы. В Российской Федерации первая редакция была принята в качестве государственного стандарта ГОСТ Р МЭК 61508 в 2007 году. В настоящее время в мире действует вторая редакция МЭК 61508, выпущенная в 2010. В Российской Федерации вторая редакция МЭК 61508 также является актуальной с 2012 года (ГОСТ Р МЭК 61508-2012). Серия стандартов МЭК 61508 включает 7 частей, которые в сумме содержат около 600 страниц текста. О назначении частей легко догадаться по их названиям. Конечно, между частями МЭК 61508 существуют довольно сложные связи, что отражено в рисунках самого стандарта: Overall framework of the IEC 61508 series (IEC 61508, Figure 1). Терминология МЭК 61508: базовые термины по безопасности Для того, чтобы разобраться с концепцией функциональной безопасности, пожалуй, начать надо, не с начала и не с конца, а с середины, а именно с четвертой части (МЭК 61508-4), где изложена основная терминология. Как видим, термины разделены на 8 групп (3.1-3.8). Эти группы логически связаны между собой. На мой взгляд, самыми важными являются группы 3.1 (Safety terms) и 3.5 (Safety functions and safety integrity). Далее термины выборочно цитируются согласно русскоязычному тексту МЭК 61508-4, а затем дается их авторская интерпретация. Итак, первый раздел по терминологии, 3.1 «Термины, относящиеся к безопасности». Смотреть термины, относящиеся к безопасности»3.1.1 вред (harm): Физическое повреждение или ущерб, причиняемый здоровью людей, имуществу или окружающей среде. 3.1.2 опасность (hazard): Потенциальный источник причинения вреда 3.1.6 риск (risk): Сочетание вероятности события причинения вреда P(t) и тяжести этого вреда C. 3.1.7 допустимый риск (tolerable risk): Риск, который приемлем при данных обстоятельствах на основании существующих в обществе ценностей. 3.1.11 безопасность (safety): Отсутствие неприемлемого риска. 3.1.12 функциональная безопасность (functional safety): Часть общей безопасности, обусловленная применением управляемого оборудования (УО) и системы управления УО, и зависящая от правильности функционирования систем, связанных с безопасностью, и других средств по снижению риска. 3.1.13 безопасное состояние (safe state): Состояние УО, в котором достигается безопасность. Я попытался связать все сущности в единое целое, и в результате получилась следующая схема (пожалуй, можно назвать ее онтологией). Важно отметить, что компьютерная система управления (КСУ) является лишь одной из многих мер по снижению рисков. Существует множество так называемых пассивных мер защиты, например, ремень безопасности в автомобиле или в самолете. Риск является показателем безопасности, и на понятии риска необходимо будет обратить внимание в дальнейшем, при рассмотрении этих самых показателей. Пока приведу простой пример. Ходит зачем-то человек по краю крыши. Вероятность падения с крыши при прочих равных условиях не зависит от высоты здания. А вот степень ущерба зависит. Тогда и риск падения с крыши 10-этажного здания будет выше, чем риск падения с крыши одноэтажного здания. А вот риск падения с крыши 10-этажного здания практически равен риску падения с крыши 100-этажного здания, поскольку, если вероятность падения одинакова, то и последствия (ущерб) падения здесь, к сожалению, также одинаковы. Интересным, на мой взгляд, является понятие допустимого (приемлемого) риска. Оно зависит от исторического и гуманитарного контекста. Правда ли, что наивысшими ценностями современного общества является человеческая жизнь и забота об окружающей среде, которая формирует и поддерживает эту самую жизнь? Реальное состояние техногенных объектов демонстрирует, насколько государство и общество реализуют провозглашенные ценности. Еще одним принципиальным понятием является «безопасное состояние». Например, одна из важнейших систем безопасности, система противоаварийной защиты (ПАЗ), должна остановить функционирование управляемого объекта. Как это происходит? Как правило, путем разрыва электрических цепей (это уже зависит от технологических алгоритмов управления оборудованием), что происходит путем перевода выходных дискретных сигналов в состояние «логический 0» (так называемый принцип de-energize to trip, чтобы система могла отработать и при аварийной потере электроснабжения). При необходимости, «логический 0» может быть инвертирован в «логическую 1» через промежуточные реле. Терминология МЭК 61508: термины, относящиеся к функциям безопасности и полноте безопасности (safety integrity) В первой части цикла статей я уже вкратце упоминал, что понятие функциональной безопасности включает в себя реализуемые функции безопасности и полноту (интегрированность) выполнения этих функций. В МЭК 61508-4, раздел 3.5 «Функции безопасности и полнота безопасности» приводятся соответствующие термины. Смотреть термины, относящиеся к функциям безопасности и полноте безопасности3.5.1 функция безопасности (safety function): Функция, реализуемая Э/Э/ПЭ системой, связанной с безопасностью, или другими мерами по снижению риска, предназначенная для достижения или поддержания безопасного состояния УО по отношению к конкретному опасному событию 3.5.4 полнота безопасности (safety integrity): Вероятность того, что система, связанная с безопасностью, будет удовлетворительно выполнять требуемые функции безопасности при всех оговоренных условиях в течении заданного интервала времени. 3.5.5 полнота безопасности программного обеспечения (software safety integrity): Составляющая полноты безопасности системы, связанной с безопасностью, касающаяся систематических отказов, проявляющихся в опасном режиме и относящихся к программному обеспечению. 3.5.6 полнота безопасности, касающаяся систематических отказов (systematic safety integrity): Составляющая полноты безопасности системы, связанной с безопасностью, касающаяся систематических отказов, проявляющихся в опасном режиме. 3.5.7 полнота безопасности аппаратных средств (hardware safety integrity): Составляющая полноты безопасности системы, связанной с безопасностью, касающаяся случайных отказов аппаратуры, проявляющихся в опасном режиме. 3.5.8 уровень полноты безопасности; УПБ [safety integrity level (SIL)]: Дискретный уровень (принимающий одно из четырех возможных значений), соответствующий диапазону значений полноты безопасности, при котором уровень полноты безопасности, равный 4, является наивысшим уровнем полноты безопасности, а уровень полноты безопасности, равный 1, соответствует наименьшей полноте безопасности. 3.5.9 стойкость к систематическим отказам (systematic capability): Мера уверенности (выраженная в диапазоне ССО 1 — ССО 4) в том. что систематическая полнота безопасности элемента соответствует требованиям заданного значения уровня полноты безопасности (УПБ) для определенной функции безопасности элемента, если этот элемент применен в соответствии с указаниями, определенными для этого элемента в соответствующем руководстве по безопасности. 3.5.16 режим работы (mode of operation): Способ выполнения функции безопасности либо в режиме: — с низкой частотой запросов (low demand mode), в котором функция безопасности выполняется только по запросу и переводит УО в определенное безопасное состояние, а частота запросов не превышает одного в год или — с высокой частотой запросов (high demand mode), в котором функция безопасности выполняется только по запросу и переводит УО в определенное безопасное состояние, а частота запросов превышает один в год, или — непрерывном режиме (continuous mode), в котором функция безопасности поддерживает УО в безопасном состоянии, как и при нормальном функционировании. С точки зрения приводимого определения полноты безопасности (safety integrity), это свойство фактически сводится к безотказному выполнению функций безопасности, т.е. рассматривается, как часть безотказности, которая, в свою очередь, является составляющей классической надежности. На самом деле, из других положений МЭК 61508 следует, что полнота безопасности является более сложным свойством, связанным с такими атрибутами, как ремонтопригодность, готовность, долговечность, информационная безопасность. Терминологические и таксономические аспекты составляющих надежности и безопасности представляют собой смежную область знаний. Возможно, в последующих публикациях есть смысл разобраться в этом подробней. Еще одним центральным понятием в МЭК 61508 является уровень полноты безопасности (Safety Integrity Level, SIL). Значение SIL устанавливает в зависимости от того, насколько влияние управляемого оборудования создает риск для людей и окружающей среды. Исходя из этого, установлен риск отказа и для самой компьютерной системы управления. Например, в начале статьи я уже говорил, что для системы защиты атомного реактора наработка на отказ должна составлять не менее, чем 10 миллионов часов. Это соответствует SIL3. Вообще, принято считать, что SIL4 могут соответствовать лишь наиболее простые устройства. Для программируемых логических контроллеров (ПЛК), используемых в АСУ ТП, достижимым является SIL3. Из структуры определений также следует, что полнота безопасности делится на две составляющие: полнота безопасности, касающаяся систематических отказов (сюда же попадает полнота безопасности программного обеспечения) и полнота безопасности аппаратных средств. Первая составляющая требует применять меры защиты от систематических отказов, вызванных ошибками проектирования. Для этого необходимо совершенствовать процессы проектирования и разработки, тестирования, управления конфигурацией, проектного менеджмента и т.п. Это отдаленно напоминает уровни Capability Maturity Model Integration (CMMI), но напрямую к ним не трассируется. Для каждого из значений SIL определен набор методов защиты от систематических отказов, причем их количество и «строгость» возрастает с повышением SIL. Полнота безопасности аппаратных средств связана с защитой от случайных отказов и обеспечивается применением компонентов с высоким уровнем безотказности и самодиагностики, и, конечно же, резервированием. Здесь есть интересный фокус, который применяют многие разработчики ПЛК. Можно достичь уровня SIL2 при одноканальной конфигурации ПЛК. Тогда резервированная конфигурация даст SIL3. При этом процессы разработки (systematic capability), должны соответствовать SIL3. Теперь, по аналогии с предыдущим разделом, попробуем применить структуру окружения (опасность, ущерб, риски, контмеры, управляемое оборудование) для компьютерной системы управления (КСУ). Здесь речь идет об опасностях для выполнения функций безопасности КСУ, поскольку их невыполнение связано с риском. Для снижения этого риска применяются различные меры по обеспечению полноты безопасности. Как мы уже знаем, эти меры направлены на защиту от случайных и систематических отказов. Попробуем теперь совместить полученную схему со схемой из предыдущего размера. Получается такая вот двухуровневая структура, демонстрирующая терминологическую среду функциональной безопасности «на пальцах». Терминология МЭК 61508: еще несколько полезных терминов Итак, согласно МЭК 61508-4, у нас еще осталось шесть из восьми разделов по терминологии. Следующий терминологический раздел: 3.2 «Оборудование и устройства». Здесь приводятся достаточно тривиальные определения, относящиеся к типам программного и аппаратного обеспечения, используемых в системах, важных для безопасности. Приведу лишь определение для упоминаемого выше управляемого оборудования. Смотреть термины, относящиеся к оборудованию и устрйствам3.2.1 управляемое оборудование; УО [equipment under control (EUС)]: Оборудование, машины, аппараты или установки, используемые для производства, обработки, транспортирования, в медицине или в других процессах. В разделе 3.3 «Системы: общие аспекты» также содержать понятные технарям определения. В разделе 3.4 «Системы: аспекты, связанные с безопасностью» содержится важное определение, отвечающее на вопрос: «а что именно подразумевается под системой, связанной с безопасностью?» Смотреть термины, относящиеся к аспектам, связанные с безопасностью3.4.1 система, связанная с безопасностью (safety-related system): Система, которая: — реализует необходимые функции безопасности, требующиеся для достижения и поддержки безопасного состояния УО и — предназначена для достижения своими средствами или в сочетании с другими Э/Э/ПЭ системами, связанными с безопасностью, и другими средствами снижения риска необходимой полноты безопасности для требуемых функций безопасности. Раздел 3.6 «Сбой, отказ и ошибка» дает определение этим досадным происшествиям. Кроме того, в данном разделе даются определения уже известным нам случайным и систематическим отказам, а также опасным и безопасным отказам. Далее следуют определение показателей безопасности, которые есть смысл рассмотреть в отдельной публикации. Смотреть термины, относящиеся к сбоям, отказам и ошибкам3.6.1 сбой (fault): Ненормальный режим, который может вызвать снижение или потерю способности функционального блока выполнять требуемую функцию. 3.6.4 отказ (failure): Прекращение способности функционального блока выполнять необходимую функцию либо функционирование этого блока любым способом, отличным от требуемого. 3.6.5 случайный отказ аппаратуры (random hardware failure): Отказ, возникающий в случайный момент времени, который является результатом одного или нескольких возможных механизмов ухудшения характеристик аппаратных средств. 3.6.6 систематический отказ (systematic failure): Отказ, связанный детерминированным образом с некоторой причиной, который может быть исключен только путем модификации проекта, либо производственного процесса, операций, документации, либо других факторов. 3.6.7 опасный отказ (dangerous failure): Отказ элемента и/или подсистем и/или системы, которые принимают участие в реализации функций безопасности, в результате чего: а) функция безопасности не выполняется, когда это требуется (для режимов с низкой или высокой частотой запросов) либо отказывает (для непрерывного режима), что приводит к переводу УО в опасное или потенциально опасное состояние; б) снижается вероятность того, что функция безопасности при необходимости будет корректно выполнена. 3.6.8 безопасный отказ (safe failure): Отказ элемента и/или подсистем и/или системы, которые принимают участие в реализации функций безопасности, в результате чего: а) приводят к выполнению функции безопасности по переводу УО (или его части) в безопасное состояние либо поддерживают безопасное состояние; б) увеличивается вероятность выполнения функции безопасности по переводу УО (или его части) в безопасное состояние либо поддержке безопасного состояния. 3.6.10 отказ с общей причиной (common cause failure): Отказ, который является результатов одного или нескольких событий, вызвавших одновременные отказы двух или более отдельных каналов в многоканальной системе, ведущих к отказу системы. 3.6.11 ошибка (error): Расхождение между вычисленным, наблюдаемым или измеренным значением или условием и правильным, заданным или теоретически верным значением или условием. Определения раздела 3.7 «Процессы жизненного цикла», как и сам жизненный цикл, являются темой отдельной публикации. Смотреть термины, относящиеся к процессам жизненного цикла3.7.1 жизненный цикл систем безопасности (safety lifecycle): Необходимые процессы, относящиеся к реализации систем, связанных с безопасностью, проходящие в течение периода времени, начиная со стадии разработки концепции проекта и заканчивая стадией, когда все Э/Э/ПЭ системы, связанные с безопасностью, и другие средства снижения риска уже не используются. В разделе 3.8 «Подтверждение мер по обеспечению безопасности» интерес представляют определения, даваемые для верификации и валидации. Сразу скажу, что обычно в жизненном цикле валидация и верификация (verification and validation, V&V) рассматривается как единый процесс. Непосредственно под валидацией понимаются испытания полностью интегрированной системы с физической симуляцией входных и выходных сигналов, а под верификацией – все остальные обзоры, анализы и тесты. Но из определений МЭК 61508 этого вовсе не следует. Смотреть термины, относящиеся к подтверждению мер по обеспечению безопасности3.8.1 верификация (verification): Подтверждение выполнения требований путем исследования и сбора объективных свидетельств. 3.8.2 подтверждение соответствия (validation): Подтверждение, путем испытаний и представления объективных свидетельств, выполнения конкретных требований к предусмотренному конкретному использованию. Выводы МЭК 61508 представляет собой достаточно пространный, сложный, порой запутанный и противоречивый стандарт, включающий в себя 7 частей. «Распутать» его можно, только применяя на практике. В основе МЭК 61508 лежит риск-ориентированный подход. Уровни риска для компьютерных систем управления назначаются в зависимости от влияния управляемого техногенного объекта на окружающую среду, а также на здоровье и жизнь людей. Для этого в МЭК 61508 введено понятие уровня полноты безопасности (Safety Integrity Level, SIL), которые установлены по возрастающей, от 1 до 4. Для соответствия тому или иному SIL необходимо реализовать меры по защите от случайных отказов аппаратных средств, а также от систематических отказов, вызванных ошибками проектирования. Поэтому, для каждого из SIL заданы требования к продукту в виде значений показателей безопасности и требования к «строгости» реализации процессов жизненного цикла. Терминология по функциональной безопасности изложена в четвертой части МЭК 61508 (МЭК 61508 4). Разобравшись с терминологией, в следующей части публикации мы сможем рассмотреть структуру и взаимосвязи для остальных частей МЭК 61508. Трактовать законы и стандарты можно по-разному, но, в любом случае, трактующий обязан осмысливать их содержание, чтобы своевременно отличить добро от зла. Кроме того, в планируемом цикле статей будут рассмотрены следующие основные аспекты функциональной безопасности: — Теория надежности и функциональная безопасность: основные термины и показатели; — Методы обеспечения функциональной безопасности компьютерных систем управления; — Жизненный цикл безопасности для системы управления; — Тестирование систем управления, важных для безопасности. Напомню, что в первой вводной части публикации: — обоснована важность оценивания и обеспечения функциональной безопасности для компьютерных систем управления; — рассмотрены архитектуры систем, для которых необходимо оценивать и обеспечивать функциональную безопасность; к таким системам относятся АСУ ТП (Industrial Control Systems) на базе программируемых логических контроллеров (ПЛК), встроенные системы (Embedded Systems) и уровень устройств (Device Layer) для интернета вещей; — кратко представлено множество стандартов, относящихся к функциональной безопасности в различных сферах применения.

Метки:  

[Перевод] Обзор физики в играх Sonic. Части 7 и 8: пружины и штуковины, суперскорости

Дневник

Воскресенье, 31 Июля 2016 г. 16:36 + в цитатник
Продолжение цикла статей о физике в играх про Соника. В этом посте рассматриваются отталкивания персонажей от различных игровых объектов и их суперспособности. Ссылки на другие части серии: Часть 1: твердые тайлы Часть 2: бег Части 3 и 4: прыжки и вращение Части 5 и 6: потеря колец и нахождение под водой Часть 7: пружины и штуковины 1 Пружинные площадки 2 Воздушные шарики 3 Бамперы 4 Пушки 5 Крышки с пружинами 6 Вертушки 7 Лифты в небе 8 Грибы 9 Разрушение стен 10 Разрушаемые блоки и камни Пружинные площадки Красные пружинные площадки придают Сонику скорость 16, а жёлтые — скорость 10. В зависимости от направления площадки (вверх или вниз), значение отрицательное или положительное, и соответственно скорости по оси Y придается это значение. Если пружинная площадка направлена влево или вправо, значение скорости отрицательное или положительное, соответственно скорость по оси X приравнивается к этому значению. Вертикальные площадки не влияют на скорость X, как и горизонтальные площадки не влияют на скорость Y. Диагональные пружинные площадки В Sonic the Hedgehog (16-bit) нет диагональных пружинных площадок. Однако они есть в Sonic 2 (16-bit), 3, Knuckles и CD. В Sonic 2, 3 и Knuckles они работают одинаково, но в Sonic CD принцип отличается. в Sonic 2, 3 и Knuckles диагональная пружина устанавливает скоростям X и Y значение пружинной площадки с соответствующим знаком. Поэтому пружина, направленная вверх-вправо придает скорость Y, равную -16 и скорость X, равную 16. Проблема этого метода в том, что технически Соник отталкивается диагонально быстрее, чем горизонтально или вертикально. Это потому, что разработчики не позаботились учесть косинусы и синусы. В Sonic CD они исправились. Удобно, что абсолютные значения синуса и косинуса угла в 45 градусов одинаковы, поэтому требуется только одно значение. Скорость становится равной 11.3125 для красных пружин и 7.0703125 для жёлтых. Блокировка горизонтального управления Когда Соник отскакивает от горизонтальной пружины (красной или жёлтой), он не может тормозить или иным способом влиять на свою скорость X в течение 16 циклов. Движок достигает этого, устанавливая ту же блокировку горизонтального управления, что и при скатывании с крутых склонов (в S3 и Knuckles байты $32-33 являются таблицей состояний объекта игрока). Зачем блокировать горизонтальное управление? При столкновении с пружиной игрок скорее всего нажимает крестовину в направлении пружины, и это может привести к отталкиванию Соника в анимации торможения. Временное игнорирование ввода — это быстрое и элегантное решение. Анимация В случае пружинной площадки, направленной вверх, когда Соник теряет всю скорость, направленную вверх, он переходит в анимацию ходьбы. Кадры этой анимации сменяются каждые 8 циклов. В случае любой из диагональных пружинных площадок Соник вообще не переходит анимации ходьбы в воздухе. Он сохраняет анимацию «штопора» (трёхмерного вращения), кадры которой сменяются раз в 5,5 цикла. Воздушные шарики При столкновении Соника с воздушными шариками на уровнях Carnival Night Zone его скорость Y устанавливается равной -7, вне зависимости от угла столкновения. Скорость X не изменяется. Бамперы Бамперы в Spring Yard Zone придают Сонику скорость X, равную 7*cos(p), и скорость Y 7*-sin(p), где p — это угол между центрами бампера и Соника. Скорость устанавливается вне зависимости скорости Соника до столкновения с бампером. Пушки Пушки в Carnival Night Zone придают Сонику горизонтальную скорость 16*cos(p), и вертикальную скорость 16*-sin(p), где p — угол наклона пушки. Крышки с пружинами Красные крышки с пружинами, которые закрывают трубы в Chemical Plant Zone, работают как пружинные площадки, но немного сильнее, чем жёлтые площадки. При столкновении они придают Сонику скорость Y, равную -10.5. Вертушки Чёрные вертушки, которые разгоняют ежа вперёд в Chemical Plant Zone устанавливают скорость X равной 16. Однако они не замедляют его, если он уже движется быстрее. Лифты в небе Лифты в небе на уровнях Hill Top Zone перемещаются со скоростью X, равной 2, и скоростью Y, равной 1. Грибы Грибы в Mushroom Hill Zone работают как пружинные площадки, однако каждый последующий отскок становится выше предыдущего (до трёх отскоков). Первый отскок придаёт скорость Y -6.5, второй -7.5, а третий -8.5. Разрушение стен В Sonic 1, 2, 3 и Knuckles для пробивания разрушаемых стен при вращении абсолютная скорость X персонажа должна превышать 4.5 (за исключением персонажа Knuckles, который крошит стены при столкновении, при этом ему не обязательно вращаться). Столкновения с такими стенами не влияют на скорость X. Однако когда Knuckles разрушает стены в Sonic 3 и Knuckles, несмотря на то, что его скорость X не изменяется, он не двигается в кадре, в котором ударяет стену. То же самое справедливо для пробивания Соником стены при вращении в Sonic 3 и Knuckles. В Sonic CD, ограничение по скорости X убрано. Соник может пробивать разрушаемые стены, просто прыгая рядом с ними или вращаясь на любой скорости. Разрушаемые блоки и камни Когда Соник запрыгивает на разрушаемые объекты, такие как камни в Hill Top Zone, блоки в Marble Zone или крышки труб в Chemical Plant Zone, он отскакивает от них со скоростью Y, равной -3. Скорость X не изменяется. Часть 8: суперскорости 1 Супербыстрые ботинки 2 Супер/Гиперсоник 3 Супер Тейлс, Супер/Гипернаклз 4 Отбор колец 5 Примечания Супербыстрые ботинки Примечание переводчика: супербыстрые ботинки (Super Fast Shoes) — это бонус увеличения скорости, действующий 20 секунд и повышающий ускорение и максимальную скорость Соника. Выбивается из вот таких мониторов: Переменная Значение Ускорение 0.09375 Торможение 0.5 (не изменяется) Трение 0.09375 Максимальная скорость 12 Ускорение в воздухе 0.1875 Трение при вращении 0.046875 Торможение при вращении 0.125 (не изменяется) Примечание: если Соник падает в воду, все эффекты супербыстрых ботинок (Super Fast Shoes) обнуляются. «Подводные» переменные полностью их заменяют. Если вы выпрыгнете из воды, эффект супербыстрых ботинок не вернётся. Похоже, что это относится ко всем 5 играм. В Sonic 3 и Knuckles темп музыкальной композиции увеличивается в 1.25 раза. Супер/Гиперсоник Примечание переводчика: Суперсоник (Super Sonic) — это суперформа персонажа Sonic the Hedgehog. Такая форма Соника впервые была применена в игре Sonic the Hedgehog 2 и в различном объёме реализовалась затем в каждой основной игре про Соника. Превратиться в Суперсоника можно, собрав все семь Изумрудов Хаоса, найдя не менее 50 колец и потеряв всю защиту. Сделав двойной прыжок, Соник становится жёлтым Суперсоником, это более быстрая и почти неуязвимая форма Соника. Однако на поддержание этой формы тратятся кольца (см. ниже). В играх Sonic 3 и Knuckles, после сбора всех Изумрудов Хаоса на специальных уровнях можно собрать семь Суперизумрудов, после чего превратиться в Гиперформу персонажа. Она также тратит собранные кольца. В этом режиме персонаж может делать направленные двойные прыжки, уничтожать всех противников на экране и не способен утонуть, в отличие от суперформы. Переменные относятся к Суперсонику в Sonic 2 и к Супер- или Гиперсонику в Sonic 3 и Knuckles, за исключением отмеченной переменной. Переменная Значение Значение (под водой) Ускорение 0.1875 0.09375 Торможение 1 0.5 Трение 0.046875 (не изменяется) 0.046875 (не изменяется) Максимальная скорость 10 5 Ускорение в воздухе 0.375 0.1875 Начальная скорость прыжка 8 3.5 (не изменяется) Скорость прыжка при отпускании кнопки 4 (не изменяется) 2 (не изменяется) Трение при вращении 0.09375 (0.0234375 в Sonic 3 и Knuckles) 0.046875 (0.0234375 в Sonic 3 и Knuckles) Торможение при вращении 0.125 (не изменяется) 0.125 (не изменяется) Способность Hyper Blast (только у Гиперсоника) Когда игрок нажимает второй раз кнопку прыжка в воздухе, скорость Соника по оси X приравнивается 8, если он смотрит вправо, и к -8, если влево, а скорость по оси Y обнуляется. Если игрок удерживает «вверх» на крестовине при нажатии на кнопку, то скорость Соника по оси Y приравнивается к -8, а по оси X обнуляется. Супертейлз, Супер/Гипернаклз Переменная Значение Значение (под водой) Ускорение 0.09375 0.046875 Торможение 0.75 0.375 Трение 0.046875 (не изменяется) 0.046875 (не изменяется) Максимальная скорость 8 4 Ускорение в воздухе 0.1875 0.09375 Начальная скорость прыжка (не изменяется) (не изменяется) Скорость прыжка при отпускании кнопки (не изменяется) (не изменяется) Трение при вращении 0.0234375 0.0234375 Торможение при вращении 0.125 (не изменяется) 0.125 (не изменяется) Скорость взбирания (только для Наклза) 2 2 Начальная скорость скольжения (только для Наклза) 4 (не изменяется) 4 (не изменяется) Ускорение скольжения (только для Наклза) 0.046875 0.046875 Стенотрясение (Wall Quake) (только для Гипернаклза) Чтобы Наклз смог сотрясти экран и уничтожить всех врагов при контакте со стеной, он должен скользить со скоростью 4.5 пикселей за цикл или выше. Отбор колец Находясь в режиме Супер/Гипер, персонаж теряет по одному кольцу каждые 60 циклов, или раз в 1 секунду. Примечания Если Супер/Гиперперсонаж получает супербыстрые ботинки, разбив монитор, переменные супербыстрых ботинок заменяют переменные режима Супер/Гипер, на самом деле замедляя персонаж (однако максимальная скорость остаётся немного выше). Это может быть нежелательно в вашем собственном движке. Когда Супер/Гиперперсонаж падает в воду, он использует указанные выше переменные. Однако, если они становятся Супер/Гипер уже под водой, переменные режима Супер/Гипер становятся такими, как будто он не находится под водой. Это баг, и его следует избегать в своём движке. P.S. снова для внимательных и любопытных читателей. Здесь в первое зашифрованное слово заканчивается. Слова не относятся к вселенной Соника, однако для расшифровки требуется её знание (впрочем, гуглением вполне можно обойтись).

Метки:  

Проецируя Google Material Design на десктопную систему… (часть вторая)

Дневник

Вторник, 05 Июля 2016 г. 21:14 + в цитатник
Краткое содержание первой части: контрактный клиент, редизайн их собственной CRM-ки, стиль Google Material, привычная среда обитания, аудитория — опытные айтишники. Кто не вдохновился первой частью и остальных тоже — приглашаю под кат… Вобщем, как вы помните, я выкатил клиенту вот такую картинку в качестве выполненного тествого задания и стал ждать ответа…. Прежде всего я хотел бы выразить благодарность скептикам из первой главы. Я и так два месяца откладывал описание этого проекта. Теперь же у меня появилась дополнительная мотивация продолжить: мне предстоит не только аргументировать свои решения, но и развеять ваши сомнения. Внимательный читатель безусловно заметил некоторые погрешности на скриншоте выше. И это замечательно! Не стоит забывать, что этот скрин — лишь результат тестового задания. Данный скрин — не целая система. Этот макет не решает проблемы пользователя или предлагает какой-то оптимальный сценарий. Это лишь “контрольная работа”, которая подается на стол потенциальному клиенту на проверку. Она основана на рестилизации одного случайно выбранного экрана старой системы. Как правило на этой стадии иногда бывает, что UI-дизайнер задаёт значение некоторым элементам/блокам/разделам, исходя из собственных догадок, а не задач клиента. Это допустимо и не критично. Дальше, как правило, дизайнер, подпитываемый верой или надеждой, ожидает feedback от клиента. Давайте теперь посмотрим на оригинал скриншота (внешний вид системы на тот момент). Именно этот раздел был выбран мной из 5 предложенных в качестве тестового задания: Что мне сразу бросилось в глаза тогда: дефолтный bootstrap, обилие форм ввода, вкладочность. Кстати, в последствии оказалось, то, что на моём тестовом задании блок “Уведомления” вообще трактован некорректно. У клиента в системе это на самом деле таски, связанные с данной задачей! Упс, я ведь оформил их совсем иначе… На самом деле на стадии выполнения тестового это моё недопонимание никого не волновало. Адекватный клиент понимает, что это еще не стадия работы “предлагать решения”. Это пока лишь “пре” стадия возможной будущей совместной работы под названием “показать подход”. Поэтому тех, кто спрашивал раньше, почему “уведомления” болтаются внизу, я успокою… Уведомлений вообще не будет :) Итак, упорядочу наблюдения: Дефолтный bootstrap. Это то, от чего клиент хочет уйти, потому как дефолтность не может обеспечить подстройки под личные нужды. Это то, про что обычно клиент говорит “Сейчас реализовано вот так, мы понимаем, что криво, но хочется немного иначе”. Обилие форм ввода. Для тех, кто в первой главе посчитал, что это “получилось очень нагромождено” скажу, что всё самое страшное еще впереди. Да, такова специфика системы Chronos: очень много параметров, которые сопровождают каждую сделку. Выкинуть нечего. Задача — не из визуально приятных, ведь к скроллам прибегать нельзя. Вкладочность. Это требование к системе. Так как сотрудникам Performance Lab зачастую одновременно приходится вести множество сделок и клиентов, то все они должны быть доступны за минимальное количество кликов. Любую вкладку можно закрыть, нажатие на любой раздел в меню слева порождало новую. Итак, скооперировавшись с аналитиком компании, который как оказалось тоже предпочитал Андроид, мы начали. Аналитик прекрасно знал требования пользователей, их поведенческие сценарии и их проблемы. Взаимодействовать с ним было сплошным удовольствием. Дизайнер интерфейсов должен проявлять колоссальное любопытство и внимание к пользователям и процесс движется эффективнее, когда у аналитика уже есть набор всех данных об их поведении. Сделки Раздел “Сделок” представляет из себя стандартный подход в виде воронки продаж. Для компании существует около 10 стадии ведения клиента. От “холода”, потом к “всё теплее” и в конечном итоге самая “жара” — это успешная продажа. Цель данного раздела в CRM “Chronos” — дать понимание количества сделок в каждой конкретной стадии, представить их денежный объем, показать задействованных сотрудников и, если надо, выделить просроченные. Я начал работу согласно всем текущим трендам: обилие отступов, наполненность воздухом и никакой тесноты для элементов: Попутно я предложил новую цветовую гамму для всех стадий продаж, основываясь на цветах, предлагаемых правилами Google Material (вот удобный ресурс для подбора цвета по этим правилам): Было Стало (от “холода” к продаже, в самом конце неприятное — красным, если сделка сорвалась, серым — если заморожена) Для отображения информации по всем сделкам в табличном виде был предложен следующий режим переключения вида (по клику): Каждая сделка была представлена в виде карточки: Последовательность подачи информации для каждой сделки выглядела следующим образом: сначала необходимо сделать акцент на сумме сделки, вторичнее по значимости идёт человек за неё ответственный, и только потом имеет значение название и описание сделки. За иконкой вертикального троеточия можно прятать любой дополнительный функционал (сохранить, экспортировать, поделиться, да мало ли чего еще потребуется). Нажимая на иконку “глаз” мы вызываем попап с параметрами отображения: можно выводить только определённые стадии сделок, или же выводить сделки только от определённых людей (заказчики, КАМы, пресейлы): Конечно, нельзя не упомянуть об отречённой и болтающейся одиноко floating button (ведь мы же следуем гайдам Гугла, если вы не забыли) в правом нижнем углу. Она пригодится для создания новой сделки … Первые проблемы По старой доброй традиции кое-какую важную информацию на старте клиент “подзабыл”. А именно… “Кстати, у нас же 80% пользователей системы бегают по офису с ноутами! И все они с разрешением 1366х768. А давайте-ка все макеты “запилим” в этот размер экранчика”. Лолштооо?! Когда разрешение 1300 было ходовым, мир не знал ни материального дизайна, ни солидных отступов, ни концепции “воздушности” в интерфейсах. Была поставлена задача любой ценой и жертвами уложить в это разрешение 6 стадий сделок. Да потеснить все элементы так, чтобы для каждой стадии было видно 4 карточки. Ну и ну! Получается, что во-первых: я должен урезать макет по высоте до реалистичной ноутбуковской высоты 768, а во-вторых: внедрить 4ый ряд карточек… Прощай “наполненность воздушностью” :( Но таковы требования к функционалу системы. Аналитик знает, что говорит, и мне приходится действовать в появившихся ограничениях. Первые решения Меня успокоили тем, что если и будет планироваться версия для мобильных устройств, то к ней будет индивидуальный подход. Сказано — сделано: Хорошей новостью оказалось то, что левое меню можно свернуть, тогда взору предстаёт более широкая картина: Раздел параметров отображения тоже пришлось потеснить и дополнить. Т.к. “внезапно” выяснилось, что будут сценарии, когда захочется фильтровать и выводить сделки за определенный период и находящиеся в определённом денежном диапазоне: (для визуального примера выполнена фильтрация еще и по людям: два заказчика, два пресейла, два КАМа) Наверное будет не лишним показать с чего всё начиналось… Разумеется этот скриншот сделан клиентом с экрана шириной 1920 пикселей, поэтому он способен отобразить больше информации: В следующем выпуске я расскажу о табличном виде и взаимодействии с формами внутри CRMки “Chronos”...
Введение в ReactiveUI: коллекции

Метки:  

 Страницы: [1]