LED дисплейна табла за болници за опашки и извънредни съобщения

Обажданията в опашка, указанията за помещения, временни съобщения и инструкции за извънредни ситуации следват различни оперативни правила. Всеки обект също има собствено разстояние за четимост, ниво на околна светлина, акустичен лимит, условия за монтаж и работен процес за обслужване.

Задачата при планирането е да се свържат тези условия с четим текст, контролирани права за публикуване, надеждни интерфейси, тихо термично поведение и тествана възстановяваемост. Това ръководство обхваща залите за регистрация, чакалните, коридорите на отделите, фоайетата на амбулаторните клиники, зоните на аптеките и сценариите за спешни съобщения. То също предоставя матрица на зоните, чеклиста за интерфейси и права, матрица за тестване на устойчивост и пълен чеклист за приемане на обекта.

Планиране на областите

1. Съпоставете всяка болнична зона с подходящото съобщение

Болничните сгради включват няколко информационни среди. Единствен шаблон за екран рядко работи ефективно във всички от тях. Регистрационните гишета управляват пристигането на пациенти и стъпките по обслужване. Зоните за чакане управляват текущи обаждания. Коридорите подпомагат бързи решения за маршрути. Големите фоайета могат да комбинират ориентация, промени в услугите и спешни инструкции.

Започнете с инвентаризация по зони, преди да обсъждате техническите спецификации на панелите. За всяко местоположение запишете основната задача, източната система, модела на гледане, работните часове и отговорния отдел. Този подход предотвратява конкуренцията между рутинни съобщения, актуализации на опашките и спешни инструкции за едно и също пространство.

Зони за регистрация и плащане

Зоните за регистрация изискват кратка и незабавна информация. Често срещаните полета включват кода на активната опашка, номера на гишето, състоянието на услугата и временния затвор на гишето. Краткото насочване по процеса може да се появява в отделна зона, но не бива да конкурира текущото обаждане.

Позицията на екрана може да има по-голямо значение от номиналните му размери. Екранът, поставен директно зад персонала, може да бъде закрит от стоящите опашки. По-високата позиция подобрява видимостта, макар че прекалено високото разположение може да затрудни четенето на малък текст. В проучването трябва да се проверят както линиите на поглед за стоящи, така и за седнали лица.

Зоните за плащане и издаване на документи могат да следват подобна логика за опашки. Тяхната терминология и работен поток обаче все още могат да се различават. Екранът за плащане може да изисква информация за наличността на гишета и напомняния за документи, докато екранът за издаване може да се фокусира върху стъпките за получаване или прозорците за услуги.

Публичното съдържание трябва да използва само одобрени идентификатори. Често е достатъчен код на опашката и дестинацията. Личните данни, информация за записа и клиничните данни трябва да останат извън публичния шаблон, освен ако документирана политика не разрешава използването им.

Общи зони за чакане

Зоните за чакане изискват спокоен и стабилен дизайн. Активният повик на опашката трябва да остава на фиксирано място. Скорошните повиквания могат да се появяват под него в продължение на ограничен период. Подпомагащите съобщения могат да заемат друга зона, но дизайновата подредба не трябва да се променя при всяка промяна на плейлиста.

Дългото време на престой променя визуалния подход. Бързата анимация, големите бели полета и повтарящото се мигане могат да предизвикат умора. По-умереният цикъл на съдържанието обикновено работи по-добре. Кратките преходи могат да подчертаят ново повикване, без целият екран да пулсира.

Шаблонът трябва да различава активно обаждане, скорошно обаждане и отложена опашка. Тези състояния изискват ясни етикети или позиции. Само промяна в цвета не е достатъчна, тъй като значението може да бъде пропуснато от странични места.

Аудиосигналите изискват отделен план. Някои зони може да нуждаят от кратък тон или говорено обаждане. Други могат да работят по-добре само с визуално известяване. Зоните на говорителите, диапазоните на силата на звука, правилата за повторение и периодите на тишина трябва да бъдат уточнени преди интеграционното тестване.

Коридори на отделенията и входове на клиниките

Информацията в коридорите трябва да е функционална, докато хората се придвижват. Имената на дестинациите, стрелките, указанията за етажа и номерата на стаите трябва да образуват един ясен визуален блок. По-дългите обяснения трябва да се намират на информационна дъска, печатан знак или близко информационно табло.

Имената трябва да са последователни из цялата сграда. Отдел не бива да се появява с пълното си име при входа и с неразбираемо съкращение до клиниката. Един одобрен списък с места назначение трябва да осигурява информация за печатаните табели, цифровите указатели и шаблоните за дисплеи.

Екранът на кръстовището трябва да отговаря на един незабавен въпрос: кой маршрут води до желаното място? Допълнителна информация за услугите може да се появи само ако не намалява размера или видимостта на този отговор.

Екрани при входовете на клиники могат да показват статуса на стаите, обхват на опашката или временна бележка. Макетът им може да е по-компактен, тъй като разстоянието за гледане е по-малко. Въпреки това основният текст трябва да остава видим, дори когато хората стоят близо до вратата.

Главни зали за амбулаторно обслужване

Големите зали често обединяват няколко функции. Типичното съдържание включва ориентация по отдели, обобщения на опашки за няколко отдела, временни промени в услугите и указания за извънредни ситуации. Макетът трябва да прави тези функции визуално отделени.

Големината на екрана не оправдава изпълването на всяка област със съдържание. Допълнителното пространство е по-полезно, когато увеличава размера на текста, полетата и разстоянията между елементите. Просто тризоново оформление може да предава информация по-ясно от плътна мозайка от съобщения.

Централният екран в хола може да изисква няколко режими на работа. Обичайният режим може да показва насоки и резюмета на опашките. Режимът за натоварен период може да увеличи информацията за текущите опашки в реално време. Режимът за аварийна ситуация трябва да замени обичайната мрежа чрез одобрен принудителен режим.

Погледът може да започне от входовете, асансьорите, ескалаторите или страничните коридори. Отбележете всеки основен подход като отделна точка за проверка на плана на етажа. Екранът, който работи добре от центъра, може все пак да се провали при наблюдение от страничен вход.

Зони за аптека, образна диагностика и лаборатория

Екраните в аптеката могат да показват кодове за вземане, номера на прозорчета и статус на услугата. Активното повикване трябва да остава доминиращо, докато скорошните повиквания трябва да изтичат според местния работен процес. Неограничената история на повиквания бързо прави оформлението трудно за преглед.

Областите за визуализация и лабораторни изследвания също могат да изискват напомняния за подготвителни процедури, указания към гардеробните или съобщения за забавяне. Тези области често имат по-дълги периоди на престой, затова движението и аудиосигналите трябва да се контролират.

Публичните екрани не бива да показват ненужни медицински подробности. Когато са необходими идентификатори, форматът на полето трябва да следва утвърдената политика за поверителност и информационна сигурност.

Мапирането на помещенията трябва да се счита за конфигурационни данни. При промяна на помещение всички свързани екрани трябва да се актуализират, без да се променят несвързани отдели. Контролираната карта на разположението намалява ръчното редактиране и противоречивите указания.

Матрица на болничната зона, съдържанието, разстоянието и изискванията към дисплея

Следващата матрица подпомага ранното определяне на обхвата. Измерванията на място трябва да заменят всички предположения, преди окончателно да бъдат утвърдени стъпката на пикселите, размерите и височината на монтиране.

Добавете ID на екрана, справочен чертеж, собственик на съдържанието и технически източник към всеки ред от матрицата. Това превръща таблицата в работен проектен документ, а не в обща препоръка.

Матрицата трябва да определи също така най-дългото име на дестинация и най-големия формат на опашка, очаквани във всяка зона. Тези стойности се използват директно в теста за четимост в следващия раздел.

Четливост

2. Задайте размера на символите според разстоянието до екрана и скоростта на изпълнение на задачата

Четимостта на текста зависи от разстоянието, височината на символите, дебелината им, интервалите между тях, височината на монтиране и скоростта на движение. Пикселното разстояние влияе върху детайла на изображението, но не решава проблема с лошо подреденото съдържание. Екран с фин пикселен размер може да се провали, ако номерът на опашката е твърде малък.

Запишете както най-близката полезна позиция, така и най-далечната смислена позиция. Най-близката физическа точка може да няма значение, когато човек минава направо под екрана. Полезната позиция е там, където информацията трябва да бъде разпозната и обработена.

Измерете цялата зона за гледане

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

Височината на монтиране променя ефективното разстояние. Високото монтиране може да подобри видимостта над тълпата, но също така увеличава вертикалния ъгъл. Ниското монтиране може да е по-лесно за четене, но е по-уязвимо към препятствия.

Скоростта на ходене също променя количеството информация, която може да се прочете. Инструкцията в коридора може да остане видима само няколко секунди. Обаждането за опашка за седнали клиенти може да остане в полезрението няколко минути.

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

Вземете всяко ниво на текст и му определете конкретна задача

Активният код на опашката изисква незабавно разпознаване. Той трябва да доминира в композицията. Приписаната му каса или стая трябва да се появяват до него, с ясно подравняване. Подпомагащите инструкции трябва да останат отделни и по-малки.

Насочващата информация използва друга йерархия. Местоназначението, стрелката и референцията за етажа трябва да се четат като един блок. Зрителят не бива да търси по целия екран, за да свърже стрелката с нейното местоназначение.

Съобщенията за аварийни ситуации изискват ред за действие преди обяснение. „Използвайте изхода на изток“ комуникира изискваното действие по-бързо от абзац, описващ защо друг маршрут е недостъпен. Допълнителният контекст може да се появи отдолу, когато позволява мястото.

Подпомагащото съдържание не бива да конкурира основната задача. Напомнянията за подготовка могат да се поставят под областта за опашка, но активното повикване трябва да остане по-голямо, по-ясно и пространствено отделено.

Използвайте типография, която подпомага бързото разпознаване

Чистият шрифт без засечки обикновено поддържа кратки полета с информация. Избраният шрифт трябва също така да поддържа всички необходими езици, формати на числа и символи. Резервният шрифт трябва да бъде тестван преди одобряване.

Тежкият текст може да подобри видимостта, но прекалено дебелото начертание може да затвори малките пространства вътре в буквите. Компресираният текст спестява ширина, макар че може да забави разпознаването. Кратките етикети и подходящото разстояние между символите често дават по-добър резултат от тесните знаци.

Използването на първа главна буква (sentence case) е подходящо за повечето инструкции. Главните букви остават полезни за кратки кодове или идентификатори на зони. Дългите инструкции, написани изцяло с главни букви, са по-трудни за сканиране, особено при странично гледане.

Числата и буквите също трябва да бъдат тествани заедно. Форматите за опашки може да съдържат символи като нула и буквата O. Избраният шрифт трябва да прави ясно различие между тези комбинации.

Броят на редовете трябва да остане ограничен. Две кратки реда обикновено се четат по-бързо от един претрупан ред. Важни са и безопасните полета, тъй като текстът от край до край може да изглежда компресиран след инсталиране.

Изпълнете пълен тест за четимост

Тестовото съдържание трябва да използва най-дългото име на отдел, най-големия код на опашка, многоезичен текст и действителни стрелки за посока. Удобна кратка етикетка не може да разкрие дали крайният шаблон ще прелива.

Изпълнете същия тест при дневни и вечерни настройки. Яркото изходно изображение може да направи тънките линии да изглеждат по-широки. Ниското изходно изображение може да намали разделянето между тъмните оттенъци. Типографията и работното ниво трябва да бъдат одобрени заедно.

Помолете наблюдателите да определят активния код, дестинацията и необходимото действие от всяка маркирана позиция. Запишете пропуснати знаци, бавно разпознаване, отрязани думи и неясни стрелки. Шаблонът трябва да бъде променен, преди спецификацията на екрана да бъде фиксирана.

Запазете работния лист свързан с одобрената версия на шаблона. По-късните промени в дизайна не трябва да намаляват височината на символите или разстоянията, които са изпълнили първоначалния тест.

Визуален комфорт

3. Баланс между висока контрастност, ниско ниво на изходен сигнал и странично гледане

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

Силният контраст може да подпомага четливостта на текста без прекомерна светлинна мощност. Тъмни или неутрални фонове често намаляват общата излъчена светлина. Цветовете на текста трябва да остават ясно различими дори при най-ниския одобрен работен режим.

Одобряване на най-ниския работен режим

Работата на ниско ниво не е просто намаляване на яркостта. Екранът трябва да запази тънките линии, цветовия баланс и еднородността. Одобряването трябва да включва и най-тихите вечерни условия, а не само демонстрация при ярко дневно осветление.

Големите бели области могат да се възприемат като рязки в съседните седалки. По-тъмният дизайн може да намали визуалната нагрузка, но тъмните фонове не бива да скриват син, сив или червен текст. Всеки одобрен цвят-комбинация трябва да се тества в реален мащаб.

Планираните профили могат да поддържат работа през деня, вечерта и през нощта. Може да се разгледа и автоматично управление. За избрания системен вариант трябва да се определят позицията на сензорите, скоростта на отговор, ръчното преминаване в резервен режим и поведението при отказ.

Промените в профила трябва да остават плавни. Внезапна промяна може да привлече внимание или да направи екрана за кратко време неприятен за гледане. Достъпът до контролите на изхода също трябва да остане ограничен след пускането в експлоатация.

Тестване на страничното гледане от реални траектории

Указан ъгъл на гледане не замества проверка на място. Теглото на текста, цветовете и контрастът могат да се променят, преди изображението да стане технически невидимо. Полезната граница на гледане е там, където информацията все още е функционална.

Проверете кодовете на активната опашка, стрелките, имената на дестинациите и аварийните цветове от всяка маркирана позиция. Екрани с високо разположение трябва да се проверяват и отдолу. Този тест може да разкрие тънки линии или отражения, които не са видими от центъра.

Механичната подравняване трябва да се извърши в рамките на същия тест. Шевовете по шкафовете и малките разлики във височината често стават по-забележими под ъгъл. Равността и калибрацията трябва да се оценяват с финалното съдържание, а не само с тестово видео.

Стъклени стени, полиран под и осветление отгоре могат да създават отражения в определени позиции. Обход на обекта през деня и вечерта помага за идентифициране на тези точки преди окончателното приемане.

Използвайте цвета като подкрепа, а не като единствен сигнал

Състоянията на опашките, групите маршрути и спешните съобщения могат да използват различни цветове. Всеки цвят трябва да е придружен и с дума, иконка или фиксирано положение в макета. Статусът не може да зависи единствено от цвят.

Рутинното съдържание трябва да използва умерена палитра. Когато всяко съобщение изглежда спешно, истинската спешна страница губи ефекта си. Най-силното визуално оформление се запазва само за одобрените шаблони за спешни и аварийни събития.

Тествайте одобрената палитра с бял текст, сив текст, стрелки и многозначни символи. Прегледът трябва да обхваща дневно, вечерно и странично гледане. Обща демонстрация на цветове не може да замени този набор от съдържание.

Изберете семейството на продукта след теста на съдържанието

Близко гледане, плътен текст и ограничено пространство за обслужване могат да насочват към вътрешна система с фин разстояние между пикселите. По-големи разстояния за гледане и по-просто съдържание за опашките могат да позволят друга конфигурация. Окончателният избор трябва да осигурява баланс между детайла на текста, размерите на екрана, достъпа за обслужване и архитектурата на управлението.

Следните изображения показват потвърдена малка пикселна референция на продукта за вътрешни помещения. Те не представляват завършен случай в болницата. Окончателната височина, разположението на шкафа, експлоатационният профил и конструкцията на контролера трябва да бъдат потвърдени в сравнение с проектните чертежи и изпитването на пробите.

Справочник на продукта за проекти за закрито изображение. Окончателната годност зависи от одобрените изисквания за наблюдение, поддръжка и контрол. ВИЖ ДЕТАЛИ ЗА ПРОДУКТА

Системна интеграция

4. Да се върнем. Определете интерфейсите на опашката, границите на HIS и правата за публикуване

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

Започнете с чертеж на потока от данни. Назовете източника на всяко съобщение и компонента, който го форматира за екрана. Това предотвратява неясни твърдения като HIS съвместимост от замяна на реална интерфейсна дефиниция.

Отделяне на източниците от контролния дисплей

Статусът на опашката може да идва от платформа за регистрация. Статусът на стаята може да идва от локална конзола. Планираните известия могат да идват от софтуер за информационни табла. Съдържанието за извънредни ситуации може да идва от ограничено командно интерфейс.

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

Точната архитектура зависи от поддържания интерфейс. Някои системи за опашки предлагат програмен интерфейс (API). Други използват изглед към база данни, размяна на файлове, мрежов поток, видеоизход или специализирано терминално приложение.

Проектът трябва също да посочва къде се извършва форматирането. Един източник може да изпраща необработени стойности, които промеждутъчният софтуер вмъква в шаблон. Друг източник може да предоставя напълно рендериран изход. Тези подходи изискват различни отговорности за тестване и поддръжка.

Трактиране на HIS Access като специфичен обхват

Хоспитална информационна система, често съкращавана до HIS, може да охваща множество функции. Тя не описва един универсален протокол. Всяко изявление за интеграция трябва да посочва точно източника, интерфейса, полетата, метода за сигурност и процедурата за тестване.

В някои проекти платформата за опашки вече получава необходимата информация. Дисплеят след това се свързва само с тази платформа за опашки. Други проекти могат да използват посредничещ софтуер, който получава одобрени полета от няколко системи.

Публичните дисплеи трябва да получават само минималните необходими данни. Често използваните полета могат да включват код на опашката, щанд, стая, отделение, време на повикване, език и статус.

Всеки поле трябва да бъде маркирано като задължително, опционално или забранено. Максималната дължина, форматът на символите и поведението при липсващо поле също трябва да бъдат документирани преди одобрение на шаблона.

Съгласувайте метода за актуализация със съобщението.

Планираните съобщения могат да използват платформа за публикуване на съдържание. Съобщенията за опашки обикновено изискват актуализация, задвижена от събитие. Временните промени в маршрута изискват целева зона, начално време, време на изтичане и отговорна роля.

Съобщенията за аварийни ситуации изискват по-бърз и по-ограничен път. Предварително одобрените шаблони намаляват редактирането по време на инцидент. Процесът на пускане трябва да остане достатъчно прост, за да може обучен персонал да го използва под натиск.

Всеки тип съобщение също изисква правило за отмяна. Съобщенията за опашки може да изтекат автоматично. Временните съобщения могат да завършат в планирано време. Съдържанието за аварийни ситуации може да изисква ръчна отмяна от упълномощено лице.

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

Интерфейс на системата и чеклиста за разрешения

Определяне на поведението при неуспех преди тестване

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

Правилната реакция варира според областта. Екран в коридор може да показва статични указания. Екран в аптека може да изисква ясно съобщение за услугата. Централен хол може да запази навигацията, като премахне само недостъпното хранене.

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

Включете загуба на източник, повреда в междинен софтуер, блокиран достъп до мрежата и рестарт на плейър в теста на интерфейса. Резултатът трябва да посочва какво се показва публично и как се възстановява нормалната услуга.

Операции и поддръжка

5. Планиране на тихо охлаждане, дълги работни часове и достъп за почистване

Дисплеите могат да бъдат разположени до консултационни стаи, зони за чакане или административни работни места. Шумът от вентилаторите, турбулентността на въздушния поток, люлеещите се панели и вибрациите от захранващото устройство могат да станат забележими по време на тихи периоди.

Акустичното планиране трябва да започне с пълната инсталация. Конструкцията на кабинета, стенният отвор, вентилацията, температурата в помещението и режимът на работа всички влияят върху крайния резултат. Прост етикет „без вентилатори“ не може да замести този преглед.

Проверете шума там, където работи екранът

Измерете шума в близост до седалките, работните места и границите на помещението. Измерване само до кабинета може да пропусне отражения от стените или тавана. Вградените конструкции също могат да усилват вибрациите.

Изпълнете реалистично съдържание по време на проверката. Ярък пълен екранен образ може да създаде различна топлинна натовареност в сравнение с обичайното съдържание за опашка. Шаблонът за аварийно съобщение също трябва да бъде включен, ако използва по-голяма ярка област.

Трябва да се регистрира нормалното фоново състояние. Дисплей, който изглежда тих по време на строителството, може да стане по-забележим след откриването на сградата и премахването на временни устройства.

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

Пазете въздушния поток и обслужващото пространство

Вградените екрани изискват определен вход, изход и обслужващ отвор. Декоративните панели не бива да покриват вентилационните зони. Топлият въздух не бива да навлиза в непредвидена запечатана кухина.

Разположението на климатичните изходи в близост трябва да е посочено на чертежа. Силният директен въздушен поток може да създаде неравномерни условия по цялата повърхност на екрана. Свързаните кабелни групи също трябва да останат извън вентилационните пътища.

Вентилационните пътища не бива да насочват прах към съседни места за сядане или чувствителни помещения. Местоположенията на входа и изхода трябва да се прегледат заедно с архитектурната облицовка.

Всеки филтър или сменяема капачка изисква метод за инспекция. Планът за поддръжка трябва да следва потвърдените инструкции за продукта, а не универсален интервал за почистване.

Проектиране за практически поддръжка

Поддръжката отпред може да помогне при коридорни и плоски (изравнени със стената) инсталации. Отделката на стената все пак трябва да оставя достатъчно място за изваждане на модулите. Декоративните елементи, таванските особености и близките информационни табели не бива да пречат на пътя за поддръжка.

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

Продължителната експлоатация също изисква политика за рестарт. Някои дисплеи може да останат активни през целия ден. Други могат да следват контролиран график за изключване. Режимът на работа трябва да съответства на работното време на отдела и на използването в извънредни ситуации.

Потвърждаване на граници за почистване

В болниците почистването включва честа грижа за повърхностите. Не всяка течност или дезинфектант е подходящ за LED маски, покрития, фина завършена облицовка на шкафове или уплътнения. Инструкциите за почистване трябва да съответстват на избрания продукт.

Процедурата за предаване трябва да посочва дали е необходима изолация на електропитанието, кой тип кърпа е подходящ и как се предотвратява проникването на течности. Тя трябва също да определя кой има право да отваря електрическите отсеки.

Съседните стени могат да понасят по-силни продукти в сравнение с повърхността на екрана. Границите за почистване трябва да бъдат ясно маркирани. Често проста илюстрирана инструкция е по-полезна за рутинната поддръжка от технически чертеж на шкаф.

Персоналът за почистване трябва също да знае как да реагира при случайно разливане. Процедурата трябва да определя стъпката за изолация, маршрута за докладване и упълномощената роля за инспекция.

Подготовка на резервни части и файлове за възстановяване

Резервният план трябва да съответства на инсталираната спецификация на компонентите. Възможните елементи включват модули, силови блокове, приемащи устройства, данни кабели и компоненти на контролера. Количествата и съвместимостта изискват потвърждение за проекта.

Резервните модули трябва да остават проследими до инсталираната конфигурация. Калибрационните данни и условията за съхранение могат да повлияят върху качеството на замяната. Файлът за предаване трябва да опише процеса на замяна и повторна калибрация.

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

Аварийни и устойчиви решения

6. Придавайте приоритет на аварийните съобщения и тествайте възстановяването на електрозахранването

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

Тези поведения трябва да бъдат документирани преди започване на конфигурацията на софтуера. Неясна инструкция като „показвайте първо извънредните ситуации“ не определя целевите групи, аудиоповедението, отмяната или възстановяването.

Използвайте ясен модел за приоритетност на съобщенията

Проектът може да използва различни имена, но има нужда от еквивалентна йерархия. При конфликти на равни нива също трябва да има правило, базирано на местоположение, тип съобщение или време на публикуване.

Предварително одобряване на шаблони и целеви групи

Шаблоните за извънредни ситуации трябва да използват фиксирани полета и одобрени структури на формулировките. Шаблонът може да съдържа тип на предупреждението, линия на действие, маршрут, засегната област и време на актуализация.

Многоезичните версии трябва да бъдат подготвени преди въвеждането в експлоатация. Активна извънредна ситуация не е подходящ момент да се установи, че преведеният текст вече не се побира.

Шаблонът за цял екран трябва да премахне обичайните списъци за опашка, рекламни графики и декоративни анимации. Трябва да остане само информацията, необходима за незабавното действие.

Целевите групи трябва да използват ясни имена или кодове на местоположенията. Подобните имена на групи от екрани създават риск съдържанието да бъде изпратено на погрешна сграда или отдел.

Контролиране на правата за публикуване на извънредни съобщения

Ролята на местен отдел може да изисква достъп само до близки екрани. Централна роля може да управлява няколко сгради. Правата за пускане и правата за отмяна трябва да бъдат посочени отделно.

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

Интерфейсът за публикуване трябва ясно да показва избраната целева група преди пускане. Йерархия на местоположенията или верифициран код на групата могат да намалят грешките при избора.

Където платформата поддържа регистри, трябва да се записват ролята, шаблонът, целевата група, времето на пускане и отмяната. Същите записи могат да подпомогнат по-късни прегледи на упражненията.

Синхронизирайте визуалния и аудио приоритет

Визуалното надмощие не винаги изисква аудио във всеки район. Голям входен хол може да изисква звуков сигнал. Тиха клиника може да изисква друг подход. Аудиото трябва да следва одобрените зони и обхвати на силата на звука.

Тоновете за опашката не трябва да конкурират с аварийното аудио. По време на надмощие рутинните обаждания може да се нуждаят от пауза. След като съобщението е изчистено, системата трябва да се върне към текущото си състояние, без да възпроизвежда изтекли обаждания.

Тествайте избраните говорители, яснота на тона, разбираемост на речта, закъснение, действие за заглушаване и възстановяване. Използвайте представителни фонови условия, когато е практически възможно.

Определете поведението при загуба на захранване и рестартиране

Резервната операция зависи от електрическата конструкция. Проектът трябва да определи дали екранът, контролерът, плеърът, мрежовото оборудване и аудиосистемата използват нормално захранване, аварийни вериги, захранване от непрекъсваем източник (UPS) или генераторно захранване.

Не се приема предварително определена продължителност на резервното захранване. Първо трябва да се дефинира изискваният резултат. След това може да се провери електрическата натовареност и работното време спрямо избраното оборудване.

Поведението при рестартиране изисква същото внимание. Екранът не трябва да се възстановява с тестов модел, максимален изход, остарели обаждания от опашката или старо аварийно съобщение. Одобрената карта, профил и източник на връзка трябва да се възстановят в контролирана последователност.

Мрежовите устройства, плеъри и контролери могат да се рестартират с различна скорост. Локална резервна страница може да покрие временния пропуск. Публичните екрани не трябва да показват сурови технически съобщения за грешки.

Матрица за тестове в случай на авария и възстановяване

Пускане в експлоатация и набавки

7. Приемане на проекта с истински текст, събития, аудио и тестове за възстановяване

Ярка видеодемонстрация не доказва, че система за опашки и насочване работи. Окончателното одобрение трябва да използва истински имена на дестинации, формати на опашки, интерфейсни събития, аудиозони и шаблони за аварийни ситуации.

Разделете приемането на преглед на документи, визуални проверки, интегрирани системни тестове и тестове за възстановяване. За всеки провален елемент трябва да има отговорен, дата за корекция и дефиниран повторен тест.

Прегледайте файла за предаване преди реалното тестване

Липсващите чертежи и резервни копия могат да превърнат малка неизправност в продължително прекъсване. Наборът документи трябва да съответства на окончателната инсталирана конфигурация, а не на по-ранна версия на проекта.

Пълен списък за приемане на проекта

Изпълнение на край-до-край оперативни скриптове

Започнете с истинско действие в опашката от одобрен терминал. Потвърдете целевия екран, зоната със съдържание, текста, аудиото и времето на актуализация. След това отменете или изтекате събитието и проверете крайното състояние.

Променете мапването на стая и потвърдете, че всички свързани екрани се актуализират. Несвързаните отдели трябва да останат непроменени. Публикувайте временна затвореност с изтичащо време и проверете автоматичното премахване.

Използвайте одобрен тренировъчен сценарий за тестване в случай на авария. Проверете избора на цел, приоритета на шаблона, приоритета на аудиото, отмяната и връщането към нормална работа. Изпълнете тренировъчния сценарий с контролирано прекъсване на мрежата или захранването.

Запишете очаквания резултат, действителния резултат, доказателствата, нивото на дефект, отговорната функция и датата на повторното изпитване. Само една снимка не може да докаже интерфейса, контрол на разрешенията или възстановяване.

Дефекти на ранга по оперативен ефект

Малка разлика в цвета и грешна карта на стаята нямат еднакви последици. Критичните елементи могат да включват несигурно монтиране, изложени лични данни, неуспешно превключване при аварийни ситуации или неконтролирани права за публикуване.

Основните елементи могат да включват непрочитан текст от опашката, смущаващ шум, неправилно картографиране на местоназначението или блокиран достъп за поддръжка. Косметичните проблеми могат да последват договорен план за коригиране, когато не засягат работата.

Всеки повторен тест трябва да повтори провалилата се стъпка. Общата демонстрация на продукта не потвърждава, че е бил коригиран конкретен дефект от интеграцията или възстановяването.

Подготвяне на пакета с данни за офертите и закупите

Полезно искане за оферта трябва да съдържа повече от ширина и височина на екрана. Той трябва да обяснява какво трябва да се показва на дисплея, откъде идва информацията и как ще се поддържа системата.

Пакетът трябва да включва планове на етажа, чертежи на надморската височина, позиции за гледане, предложена височина на монтаж, услуги в близост, работно време, примери за съдържание и подробности за източната система.

В раздела на интерфейса трябва да се посочват платформата за опаковки, наличната документация, тестовата среда, необходимите полета и очаквания поток от събития. Когато тези данни все още не са налични, в офертата следва да се посочи отделно обезщетението за интеграция.

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

ЧЕСТО ЗАДАВАНИ ВЪПРОСИ ЗА ПРОЕКТА

Често задавани въпроси