一种紧急呼叫的方法、紧急呼叫单元、系统及机动车辆与流程

1.所属领域为i2x(incident to everything)、机动车、机动车事故后的应急呼叫、应急协同、应急救援、智能交通，含传感、移动通信、定位、信息处理、面向场景的移动通信等技术。


背景技术：

2.机动车包含新能源汽车(依赖动力电池或非传统燃油车辆)，在较严重的事故后，如造成人员昏迷、死亡或车内人员被困在车内，不能自行脱困，在这种情形下，如传统燃油车事故导致油箱泄露与现场有明火时导致起火，或当前更为普遍的新能源车辆能量存储体如电池组等因事故导致起火及爆炸；特别是后者，通常给车内被困人员大约30秒至2分钟逃逸与被救援时间，虽然在我国标准《电动汽车用动力蓄电池安全要求》中也仅为新能源机动载具乘员留了300秒逃逸时间(但目前几起典型新能源车起火燃烧事故显示，新能源车事故后，电池起火速度快于标准要求)，这就导致机动车乘员在事故后风险增大，现有欧洲汽车强制标准中的unece r144(汽车emergency call系统，r144规则于2018年7月在欧盟生效，强制执行)从技术、应急流程到应急效果等角度，均无法适应当前机动车事故所常态面临的挑战，特别是事故含起火、落水等情形下。而在中国，对应于unece r144的强制标准正在相关部门的制定当中，但鉴于新能源车的普及以及2022年1季度中国官方通报的新能源车燃烧事故的数量、以及对应标准要求，unece r144事故后应急手段根本无法满足这种窄/短机会窗口的事件，所以急需用新的应急技术与系统，来挽救应急窗口特别窄/短的车辆事件中的车内的伤者、昏迷者的生命或保全死者遗体的尊严；同时unece r144这种并不适合目前新能源汽车事件应急的技术(救援时间窗口短、火势猛、救援单位无法及时到现场)，需要有更加有效的汽车事故后响应的技术与系统的应用，而不是机械的因要与欧洲标准一致，采用并不适合真实事故情形、也不符合国家法律规定与我国安全最佳实践的海外标准，从而真实的来提升机动车乘员、驾驶员的安全，减少因机动车、新能源车与现有应急系统技术与流程等多重原因导致的不必要的事故死亡、严重烧伤；此外，对于偶发的小孩、动物在汽车内高温致死、窒息致死、机动车水浸、落水、机动车在停放时的自燃等，现有车辆均无检出事件能力以及呼救能力，所以时有人员死亡及财产损失发生；此外，针对校车落水、起火、严重交通事故时，现有校车管理方式以及应急方式也同样不适合这种含大量脆弱个体的交通运输事件，所以易因各种因素导致的救援迟滞而导致本可挽救的生命逝去；此外，也针对客运车辆落水、坠崖、起火等严重事故时，目前同样存在的救援迟滞问题。


技术实现要素：

3.本说明书基于事故时的场景以及移动通信系统、应急呼叫系统以及全球普遍使用的应急流程等，因无法面对时间窗口期特别短的事件下去挽救人命，故而提出的紧急呼叫的方法、紧急呼叫单元、系统以及使用这些技术、功能单元的机动车等，从而通过技术手段、设备、系统以及被及时通知与指导的周围的群众、社会救援力量来挽救生命。其中，需要说
明r144 技术是事件发生后，通过车载系统语音呼叫应急呼叫公共应急平台(含政府公共或非公共的面向应急的组织)，然后确认事件后派出救援力量，鉴于不同国家的应急流程，r144在一些国家的事件确认中并不符合报警流程，特别是缺乏事件属性、情况的描述，通常就无法确认事件所以不能出警出救援或协同第三方救援(所含信息如伤亡情况、数量、机动车损失等情况无法掌握，虽然r144用msd技术发送定位信息)，这类情形如驾驶员或乘员死亡、昏迷、无法说话等，而应急呼叫平台(特别是非公)，因无手段如路侧监控等，所以更无法在给官方应急单位转接报告事件时，提供事件确认性的信息(事件属性)，所以应急效率差，在与官方应急系统沟通确认时，时间周期远远大于新能源车辆的30秒至2分钟的应急机会窗口，也不可能应对起火或落水这种情况，所以，r144从技术实现方式的底层逻辑上就无法应对事故如起火这种类形事件(流程与响应时间超过事件所容许的应急窗口期)，同样也无法应对车辆落水这类情形。
4.此外，无论消防还是交警，即便出警，也通常无法在新能源汽车的燃烧、爆炸窗口期内到达，所以挽救生命的可能，在现有多重原因制约下，仅给了事故点附近的普通百姓，而公共应急系统人员按照时间特征，在事故点附近的普通百姓及时处置、抢救后，赶到事故现场再进一步专业应急处置(如伤者医疗救护、火场控制)，从而可以规避、减少当前技术与流程下必然发生的死、伤。
5.所以基于通常30秒-2分钟的应急、救援窗口期，实现的方法是：通过车辆电子设备或/和紧急呼叫单元的传感器，感知事件，并由所述紧急呼叫单元判断事件并触发求救功能；求救信息由以下任意一种或多种方式发出，并通过手机或终端，通知事故现场的人或附近的车辆驾驶人员；所述多种方式含：求救信息通过与紧急呼叫单元无线模块互联的基站或接入点群发或广播；通过车辆对车辆(v2v)无线通信系统发送；通过车辆无线模块向c-v2x系统发送；通过应急协同系统发送至事故所在地的交通服务系统及公共应急系统；此外，如果所述紧急呼叫单元判断事件发生后，包含通过人机交互步骤，由车内人员确认求救或紧急呼叫单元自动确认求救。
6.机动车用紧急呼叫系统，含紧急呼叫单元、协同应急系统，应用上述方法，感知事件并触发求救。
7.紧急呼叫单元含传感器单元、无线通信单元、中央处理单元、存储单元、音频播放单元，通过传感器单元或/和机动车车载单元感知事件，并通过中央处理单元计算、处理并确认事件，触发语音提示，指导车内人员处置事件，或紧急求救确认，或紧急求救；求救方式包含：通过无线通信单元，经过协同应急系统通知事故地交通服务系统与公共应急系统(注：导航服务等全局类对机动车服务，可直接通知导航平台，上述信息流转一般基于无线网络，而信号、诱导、非全局的车联网则是地方交通服务系统)；通过移动蜂窝网络或无线接入点，在所述无线单元连接的基站或无线接入点中群发或广播求救信息；为了扩大求救通知范围，还可以请求无线单元所连接基站的相邻基站发送求救信息；为了扩大求救通知范围，可以向多个运营商提供紧急呼叫单元的位置信息，以此来扩大通知范围。
附图说明
8.图1、紧急呼叫的方法图。
9.图2、紧急呼叫的系统图。
10.图3、紧急呼叫单元的模块图。
11.图4、群发的方法1图。
12.图5、群发的方法2图。
具体实施方式
13.以下示例性实施例中所描述的实施方式及具体的时间、编码、数量、数值、示意图等，并不代表与本方法相一致的所有实施方式，相反，它们仅是与如所附权力书中叙述的本方法的一些方面相一致的方法、系统、功能单元；本说明书中的终端，含人机交互界面及网络连接，可用于接收信息或处理信息的终端，如车载终端、pad、智能手机、车载智能屏幕等。
14.针对应急窗口特别短的交通事件，如新能源汽车的能源存储体如电池等燃烧、爆炸，而驾驶员、乘员又因事故昏迷、死亡或卡在车中时，现行的救援方式是无法满足救出伤者与死者，所以如前文所述unece的r144规则/标准，实际无法应对这类事件的应急，同样道理，危化品运输中，当司机昏迷、被卡或死亡时，同样有危化品泄露、燃烧、爆炸等应急的窗口期，所以本方法特别适用于窗口特别短的交通事件，含新能源汽车、危化品汽车、传统能源机动车、校车、大巴等密集运输人员等车辆的交通事件/事故求救及救援；当然也适合应急窗口长的事件，如一般机动车的事故，但鉴于中国法律、最佳安全实践以及二次事故的防御等，建议采用本发明人其它i2x技术族定义的技术与系统，否则，会如同unece r144的标准一样，会造成本来有机会脱险的车内人员因使用e-call(emergency call)功能导致不能及时撤出事故车辆而因此导致二次事故，所以死亡、受伤或导致来向后车司、乘人员死亡或受伤的这类常规事故惨祸(注，事故后，司乘员应该立即下车，撤至路外安全区域，并在布置三角警示牌后，报警，否则在车内采用e-call与后台沟通事故情况，不能及时下车，极易被二次事故而导致事故车与后车的严重危险与损失)；此外还需要注意，unece r144的e-call 系统关注车内人员应急，并不针对机动车外事故伤者，而60％以上的事故死亡都是车外的弱者，所以i2x系列技术与专利是针对不同层面的交通参与者生命与财产的保护而提出，而本公开的说明书是i2x技术中针对车内司乘人员求救的技术，比如昏迷、死亡、被卡、落水、以及起火等。
15.在窗口期较短的交通事件中，常见为车内人员被挤压、卡在变形车体内无法下车、失去语言能力、失去知觉如昏迷以及已经死亡等几种情形，而对于可以自救的驾驶人员，驾乘人员应当自主立即下车(依法处置、防御二次事故)，所以本说明书中的技术在中国适合部分事故、事件场景下使用，而在其它不同国家，如法律规定事故后不准下车国家与区域，则可多种事故场景使用。
16.针对事故人员被挤压、卡在车内情形，这种情况下，虽然事故人员通常惊慌，但具备语言能力，所以其语言信息与机动车上的传感器感知信息结合，能更全面反应事故情况，所以无论属于政府的应急单位以及现场附近的救援群众，当收到对应信息时，都会获得实时的确认事件的信息甚至车、人的状态，从而有助于救援的决策。
17.针对事故人员被挤压、卡在车内，且不能说话情形，这种情况下，司乘人员上肢可能动，也可能不能动，但还有部分行为能力，但因为受伤涉及胸部、面部等，无法说话，所以确认事件时可能需要行为辅助，如车内紧急呼叫单元提示时，受伤人员如可通过敲击物体、特定发声次数或直接按下求救键，从而也能形成相对确认的信息，以通知相关营救者确认
事件发生并着手援救，这就需要人机交互系统、无论是通过图像识别或语音识别，比如对应播放声音信息后的事件者敲击次数。
18.针对事故人员因事故昏迷情形，在这种情况下，依靠车内传感器的感知，因一般系统无法检出事故人的确认性行为，但在紧急呼叫系统安装了摄像装置前提时，系统自识别或远端判断，则可判定确认事件情形，但如果没有图像装置时，仅能依赖传感器收集的信息推断。
19.而针对车内人员当场死亡时的情形，雷同昏迷时的情形，需要图像识别等传感设备，自动识别或后台人识别，但非特种车辆(危化品车与公共汽车、客车、校车等)，一般限于事件感知、触发后使用，以防泄露个人隐私。
20.同时需要注意的是，通过视频识别司机死亡或者受伤昏迷是个需要长时间观察的事情 (即便专业的人判断也有难度)，所以遇到起火等紧急事件无法浪费时间，所以事故死亡与受伤昏迷，实质在求救呼叫时属于同类事件。
21.此外，需要注意的是，机动车中的电子系统、电路系统，通常会因为事故的严重性而导致失去能力，也就是不能通信、不能供电也不能计算或感知车体中的故障、温度或如安全气囊等的弹出等，所以本说明书中的紧急呼叫单元需自带供电、自带传感器单元，以防备机动车事故时，机动车系统的电子电路系统无效。此外，本说明书中的紧急呼叫单元，与机动车的电子系统互联，当汽车遇到事故时，但其电子系统还未失灵的情形下，向紧急呼叫单元发送已经确定性的事故信息，包含且不限于：安全气囊的弹出、车体侧翻、倒翻、车体内温度超过限定度数、能源单元超过安全要求(温度、形变、短路等)、车体内有害气体浓度超标如二氧化碳、烟雾、一氧化碳或其它燃烧特征的感知、汽车行驶速度的突然改变，例如汽车从特定速度如大50km/秒在限定时间内的停止(如在半秒内)、巨大的撞击声、加速度传感或陀螺仪在同时的巨大变化或符合车辆失控时的特征模型，这与正常驾驶不相符的确认事件发生的数据，这类数据，随着传感技术的应用，会有多种信息，其中一个或与多个结合，即能确定事故发生。但因为在车内安装的紧急呼叫单元，拥有自己独立的系统(正常时的供电、充电由车电路系统供给，机动车不能供时，利用自己的充电电池供电)，所以除与汽车电子系统互联，获得机动车事件信息外，还利用自己的计算与传感电路系统，自行运算，感知所装备紧急呼叫单元的机动车是否事故，且在汽车电路已经无效时既可以感知车辆事故也可以感知车体内情况(如车易燃位置、车内高温超限、二氧化碳、一氧化碳超限、车体内有哭喊、尖叫等声音等)；此外，对于安全气囊弹出这种情形，紧急呼叫单元如在容许的情形下也应该有电路连接，这样可以确定性判断时，多一种确定性数据依据。
22.紧急呼叫单元的传感器也含车体位势、定位、速度、车体温度、车体关键部位温度(如电池组、油箱、电动或引擎位置，在汽车正常时，汽车电子设备可以通过能源管理获得电池组的情况，但失效时，紧急呼叫单元要靠自己的传感设备)，所以针对新能源车如电池组，不但能监测日常体表的温度，在超过设定温度时，例如大于摄氏80度，则需要告知驾驶员，如果已经是事件后，气囊弹出，人员昏迷，电池温度持续上升，超过设定温度如80摄氏度且还快速上升，则需要触发求救，并要依照事件属性通知、呼叫消防单位(事故属性驱动)、应急单位、周边群众组织救援。
23.下面用于说明本紧急呼叫的方法：如图1，s01为感知事故事件，这是因为在电子系统自动触发求救呼叫情形下，需要一个或多个信息才能比较准确判断事故以及事故的需要
采用本说明书中应对应急窗口特别窄(短)的功能(如向附近群众或车辆人员求救)，无论从汽车电子设备提取事故判定的信息或者是感知数据，都是来自传感器、控制单元感知、处理，无论模拟量、开关量(如气囊弹出)或是数字量的感知，这是判断事故发生时的必要输入；如前文所述，感知事故事件的主要输入分为汽车电子设备输入与紧急呼叫单元的传感单元输入。
24.在紧急呼叫单元收到信息后/或和自主感知，要基于判断的逻辑判断事件，并触发求救呼叫或人机交互功能，比如车辆突然从50km/秒，使用了0.5秒就制动了，气囊弹出，此时电池温度开始迅速升温，则紧急呼叫单元判定事故发生且有起火危险；当然判定手段还包含如汽车侧翻、倒翻等汽车非正常体位，即可判断汽车已经事故，如果添加能源模块的温度、车体温度、气体内外的有害气体含量、是否水浸，均可以用于判定事故与事故属性。
25.所以判断事件在电子系统层面，只要从一种或多重传感器获取信息均可以用于判断。在判断事件发生后，需要触发求救，一种情况是乘员昏迷或已经死亡情形，这种情形下，紧急求救系统向车内人员发出提示，如“是否确认立即求救”这类需要乘员确认的信息，如果事故人在播报的设定时间后无反应如设定秒数时，如超过20秒无响应，则自动发出求救呼叫；另外一种如果乘员可以讲话，在提示音如“是否确认求救”后，可以确认性回答，如“是”，“确认”，“救命”等，一则表明乘员尚能说话，并且还有正常意识，同时也是确认性求救的触发；此外如果是乘员不可以讲话，则在提示音含如“如不能说话，可以使劲敲击物体”，当音频拾音设备在提示后，检测敲击声后，证明乘员伤势已经导致不能说话但四肢之一还能有行为能力；如果乘员就是被卡，四肢还能动，则其可以直接按紧急呼叫单元的按钮，直接启动求救。所以从求救触发方式也可以得知乘员的特别司机的伤势情况。所以可以采用多种交互方式来确定求救呼叫，否则无交互，直接自动呼叫，则易于造成周边群众被误通知。
26.当然，判断事件后，音频系统提示应该采用本技术人在先申请的关于事故后的提示方法及系统(《一种提示、指导的方法、系统及机动车辆》)，所描述的技术与系统，基于事件所处道路属性、区域法律等，语音提示事故人赶紧下车，按照该地法定或最佳实践处置事故，而不是在车上用r144的e-call系统或紧急呼叫单元，这是98％以上事故情形或故障占道停车，乘员与司乘人员都没有遇到直接昏迷等如上述的情形，而按照事故所在地法律(如在中国)，需车停到路边(如果可以挪动事故车)，车上乘员赶紧下车、下车后抢救伤员(如有伤员)、司乘人员撤至路外安全区域，在安全情形下且需立即布置警告标志，然后再用电话报警；这也就是r144大多数事故情况下为何会与中国法律相抵触的原因，因为汽车驾驶员或乘员并不懂应急与法律，在非昏迷、被卡的情形下，在车内使用e-call功能，然后再与呼叫中心人员描述事故情形，不但是违法也容易让自己面临二次事故，造成严重损失，也给后续来车车辆带来极大风险。
27.在判断事件并触发求救后，本说明书采用的方法非传统逻辑，就是非传统语音呼叫公共应急单位如120/110等或第三方应急呼叫平台(如r144在中国区域的使用)，而是如含s03，是通过蜂窝基站区域求救，这是应急窗口特别窄的情形下的技术手段，因为对于新能源的如锂电池车而言，如果导致电池燃烧，通常就给了30秒-2分钟时间撤离(虽然国家对动力电池标准的要求是300ms)，任何传统语音呼救手段如呼叫官方呼叫中心如110/122，都无法完成语音呼救确认(伤者昏迷、失语)、内部事件流转更不要说应急人员能到达现场，所
以本说明书采用方式s03是为实现社会救助、有效救助；在应急中，社会救助是非常关键的挽救生命、减少财产损失的手段，但首先要通知周边人群，其次让热心的人有备而来，有工具、在指导(如某类车、某车型在某种情况下的有效救援方式)下救援；第三，在窗口结束前不但要能救出人，还不能搭上附近热心社会救助救人者的生命与健康；所以在事故车紧急呼叫后，现场即便看到事件的人，也会通过手机或智能终端得到该车型抢救等处置时的最佳建议，安全的判断等，并在指导下有效救人、有效规避自身风险(如普通人救人特别喜欢破拆前挡风玻璃以拉出伤员，但实际上即便手头有铁锤钢钎，也不能有效破拆前挡风，所以错误解救方式)。
28.所以基于上述3点，采用了s03，通过蜂窝基站区域群发求救，具体的实现方式是车载紧急呼叫单元中因含有3g、4g、5g或未来的下一代的移动通信功能模块，在s02触发求救时(系统判断为需要现场社会救助时，如卡、昏迷、死亡等或还有起火等的征兆或已经高温起火)，向该模组向此时所漫游而连接的基站，请求发送群发信息，从而让该基站当前提供服务的移动用户知道事件，并能了解事件并力所能及的救援(见图4、图5中不同的实现方式)。
29.同样道理，在沿着公路wifi等无线技术覆盖或者其它无线通信覆盖(如国外某些区域，全州关键区域全wifi覆盖，或者国内某些城市全城覆盖)，且手机、智能终端等设施普遍联网的情形下，s03也可以是向wifi接入点内所连接的设备求救，具体的是紧急呼叫单元含wifi模块，在所连接的ap(无线接入点)中在广播域内发出求救广播信息。
30.同理，其它无线技术也雷同，不一一详述，均为对所连接基站或接入点或类似设备，请求群发或广播域内广播，而对于智能终端或手机，其接收到求救报文后，要能对其进行处理，以让智能终端或手机的拥有者能予以及时响应(详细方法与技术见说明书后文中对应段落)，此外为了扩大求救范围，也可以向该基站或接入点的临近基站、无线接入点发送指令，使其群发或广播求救信息；需要注意的是，如果未来卫星通信技术发展后，紧急呼叫单元中含卫星上下行数据模块时，因单一卫星覆盖终端较多，范围较大，所以紧急呼叫单元向对其提供服务的卫星终端或服务单元发起求救广播请求后，该卫星发送广播，该星服务的终端收到信息后，仅基于呼叫点位置设定范围的卫星终端响应(如事件位置点半径500米内终端响应)，这样卫星终端收到信息后，基于当前自己定位与呼叫单元发出的自身定位信息，计算后，如在设定范围内，则响应，如播报、弹窗信息，或直接进入应急的协同交互界面等，而其他设定范围外终端，则因为是设定范围外，终端虽然也收到求救广播，但属于设定范围外，则无需播报等，卫星与终端通信的信令与握手或保持协议等中，可含特定信息字段，从而获知公共求救及求救点定位信息，也可以专设协议，面向应急事件，终端中在与卫星之间的协议中，可以快速识别并按照设定协议响应，从而通知终端的使用者，也就是紧急呼叫单元无线模块也可含卫星通信模块。
31.在使用s03技术或方法后，事故现场附近的群众会被及时通知到，但如果群众收到定位的经纬度(开放空间)或大概范围(非开放空间如地下、隧道)，这显然不利于救援，这也是r144中的一个致命缺陷(既然是面对小概率事件的求救，就应该考虑小概率中的关键事故点，而隧道事故就很频繁也通常很严重，比如校车在隧道中起火烧死多名学生，仅卫星定位无法获知位置)，通过msd发送卫星定位信息(隧道、地下或干扰时，无法定位)，所以在本说明书中的技术求救所发送的信息事少含一个url连接，而进入url后可以位置共享 (卫星
定位、ip定位、无线基站定位等多个方式的复合定位)，也可以是在地图标定位置的图片(但是有资源连接url)，收到求救报文的人点击连接，就会进入到含gis信息，并显示事故标点与自己的当前位置、路径提示，以便于社会救援。这也就是r144不能用msd这种技术而是要用基于包交换的技术，以提升救援的效率。
32.当然，移动运营商如果需要先人工或流程审核求救信息的情形下才基站群发求救信息时，紧急呼叫单元可以先发送请求给移动运营商面向应急群发的子系统(如果有)或发送至 s05，s05与移动运营商的系统对接，从而在事件下的群发(发送方式见图4、图5的对应段落)。
33.此外，如果在v2v车辆广泛使用的区域(欧、美)，紧急呼叫单元通过v2v的通信技术如专用短程通信技术dsrc，向周边v2v车辆发送求救信息，而针对v2v车辆，发送的信息中含定位的经纬度或行车区段信息，从而在v2v车辆的导航系统中直接标注；而至于 c-v2x车辆的终端，可以直接通过s03的方式发送，也可以通过s05方式发送。
34.而通过s05向外发送求救信息是因为道路事件中，需要对若干系统发送求救请求而且都是并行的且都是与位置有关的，所以需要通过s05与如移动运营商、交通服务系统以及公共应急系统数字对接，这样并行提供给相关体系，从而完成求救信息的发送；在校车中还含学校、校车管理单位、在公交运输车辆、大巴等，则含通知其运管单位、业主单位等。
35.其中交通服务体系就含c-v2x系统、导航服务系统、信号系统、引导、诱导系统、车路通信系统、车联网系统等(中国正用c-v2x系统替代传统意义的车联网)，也就是从多个层面并行去告知事故点附近相关车辆驾驶人员帮助救援以及视距内、外警示，规避与事故车的二次事故等。
36.这样事故点附近的车或者人都能收到求救信息，从而依据位置信息、事故车体上的传感器的提供的数据情况进行救援以及在这些数据下，后台协同平台系统能自动指导事故点人员救援。
37.此外，s05通过数字连接，向s08公共应急系统，发出求救请求，公共应急系统含交警、公安、消防、医疗，危化品或大事故还含应急、环保、道路运管等，传统r144标准仅语音呼叫公共应急系统，而在所述这种应急窗口特别短的事件里，需要并行多个公共应急系统，所以r144标准特别在中国无法应对新能源车起火的要求，也无法应对校车、公共、大巴等车辆坠河、落水、起火等情形。
38.通常而言，新能源汽车起火，公共应急单位虽然很难在窗口期内到现场但越早的到现场，比如抑制火势(如锂电池车需要大量水才可以灭火)，或者医疗救护及早到场也是对被社会救助出来伤者能生存的关键。
39.这样，无论s09(现场附近的人或驾驶员)或s10(专业应急组织与人)都被实时通知到，然后大家在各自位置与能力范围，进行救援(此外，专业应急人员也能对现场响应应急的普通群众通过系统的协同资源统一或分别指导)。
40.此外，为了提升救援效率，降低救援者受到危险、损失等，s05还提供协同，当救援者在点击进入连接后(当然也可通知时手机就弹窗致协同界面)，比如还能获得事故车型、应急救援时的建议、指导，比如对应车型如何开门、后备箱的逃生通道如何利用、破窗技巧等，此外还含该车型下在起火时，救援者如何自保以及何种情形下，要建议社会救援者放弃救援，此外还包括救援工具如尖锐的破窗器具、如降温、破窗、破门、救护包等建议与指导；
当然协同中还可含已经到场的工具，如果救援者手头有破窗工具，点击协同页面中破窗工具，则其他人也可获知破窗工具在路上，当然点破窗工具人的位置其他现场的人也可以看到，这样对救援及判断就会很有效，其他人可以准备如绳索、灭火的水等，从而让救援者可以信息实时对称。
41.此外，没有能力的现场救援者还可以通过s05发送照片视频，这样使用s05的公共应急单位的应急人员了解现场情况，从而在应急单位人员到现场过程中准备应急方案，也为愿意帮助事故者的人了解现场的情况，准备自己手头的工具，如附近洒水车被通知后直接冷却起火车辆，减轻事故损失。
42.本说明书的方法含：通过车辆电子设备或/和紧急呼叫单元的传感器，感知事件发生，并由所述紧急呼叫单元判断事件发生并触发求救功能；求救信息由以下任意一种或多种方式发出，并通过手机或终端，通知事故现场的人或附近的车辆驾驶人员，所述多种方式含：求救通过与紧急呼叫单元无线模块互联的基站或接入点群发或广播；通过车辆对车辆(v2v) 无线通信系统发送；通过应急协同系统发送至事故所在地的交通服务系统及公共应急系统；此外，如果判断事件发生后，可包含通过人机交互步骤，通过车内人员确认求救或超过设定时间自动触发求救。
43.其中，求救信息可以包含事故车位置信息、车辆储能单元属性信息(如汽油车、柴油车、新能源车)、传感器数据(如温度变化的数据、车体内气体、烟雾等的数据、电池不同部位温度信息)，或者也可含乘员状态可能的信息，如昏迷、如被卡、困等。
44.如果含摄像机时，可通过图像识别或后台人工识别方式确认驾驶员当前状态，或者乘员在车体中的位置，摄像机的图像在协同界面中也可被现场群众看到以决策救援。
45.上述方法可以明确的表明与unece r144标准采用了不同的技术方法、路径，这是因为如前文所述，机动车的电池标准以及应急时间窗口与传统燃油车完全不同，传统燃油车是泄露汽油后，需要明火才可以燃烧，而新能源车特别目前的锂电池，在碰撞挤压后，会瞬时发出超高的能量且各电池单元连锁反应，从而没法以现有r144规定技术及现有应急手段效率实施救援，特别人困车中时。
46.而基于本说明书的公开的方法，对应的系统如图2所示：在机动车用紧急呼叫系统中，需要两个部分的感知设备，一方面是机动车自带的传感单元，含开关量、模拟量与数字量单元，这些单元与机动车车载单元互联或者通过各自系统的控制单元与机动车车载单元互联，这样机动车在启动后，车的各种关键部件的运行状态是被监测状态下，如机动车事故时，通过减速时间、加速度变化、车体的体位(判断侧翻、倒翻等)、车体内有毒气体、温度、关键部位的温度(如电池组温度超过80度且还在加速升温等)、安全气囊的弹出等，从而判断事故停车；但是如果遇到事故严重，电路系统直接损坏的情况下，所以需要紧急呼叫单元有自己的传感单元，如在新能源电池车中含对电池组温度传感检测、车内有毒气体传感检测、温度检测、定位及速度计算、加速度变化、汽车位势等的传感检测，也可以扩展图像功能(摄像机)，以用于确定司驾人员是受伤还是已经无意识状态等。
47.紧急呼叫单元在根据传感器单元的信息或/和机动车车载单元的信息，按照判断逻辑计算并判断事故后，确认事故发生并语音提示、指导驾驶人员，如驾驶人员被困且有互动，如语言回答需要求救或有敲击或者有肢体确认行为如按下求救键、所以如r144标准类似，含 sos键与语言确认，但增加了其它人机交互的方式，如敲击、视频识别，以及事件后，
应急系统可以直接调取紧急呼叫单元的视频信号，检测车内情况(鉴于新能源车，自动驾驶车辆中已经富含各种传感器及记录设备)。当然视频摄像机可以在紧急呼叫单元里增加ai功能，识别现场情况，如识别伤者被卡、困或伏倒、气囊蹦出，驾驶员在数秒内有无反应等，识别结果作为求救的信息内容。
48.当然紧急呼叫单元也可含备份开门控制电路，在机动车电路故障以及事故识别后或按下sos键，开门解锁，以减少救援的难度与提升伤者的存活概率(虽然在汽车强制标准中要求汽车在气囊弹出后，机动车车门自动解锁，但现实中，经常有电路损坏而无解锁情况)。
49.如果使用紧急呼叫单元的汽车使用地在v2v使用国家，则该单元含v2v通信模块，可以向该类无线通信的车辆发布求救信息；对于全球主要区域，路侧蜂窝移动无线服务覆盖较广泛，所以采用蜂窝通信模组通信，如3g、4g、5g，紧急呼叫单元在判断事件并触发求救后，通过通信协议，请求4g、5g等蜂窝通信的模组所漫游的基站，向该基站请求群发信息，信息可以为传统的短信，也可以为富媒体的信息或者含求救信息的url连接，收到信息的人通过短信或富媒体及url了解到事故点及需要的救助与需要注意的内容。
50.当然如前文所述，如果机动车辆行驶地wifi等类型的无线网络覆盖较多，也可以含基于无线接入点广播域广播，报文如上所述，含求救信息，可以是提醒，也可以是富媒体报文或url。
51.此外紧急呼叫单元还将通过无线网络将报文发送协同应急系统，其与协同应急系统包交换网络互联，从而可以传输应急所需的数据如传感器数据、视频等，同时触发应急协同系统并行发送信息至公共应急系统及交通服务系统，如图2中的ts01至ts05；此外对于不能直接请求基站发送群发求救的情况下，协同应急系统与移动运营商系统互联，按照双方约定的报文形式，请求移动运营商向事故点紧急呼叫单元所漫游的基站发出群发指令，而群发的报文由协同应急系统从紧急呼叫单元获的或基于其提供的基础数据，根据信息以及运算逻辑，形成更全面的求救信息或报文，从而以让移动运营商系统指令紧急呼叫单元移动通信模组当前漫游基站发出指令群发求救信息。
52.此外，目前的交通服务系统并不含社会救助能力，所以当信息发送这类系统后，这类系统需要增加社会救助功能，如路面或路侧诱导系统，就应该实时发布如“前方500米，某类新能源车事故，需要救援，请能提供救援的驾驶人员从应急车道到事故点”，在c-v2x系统，车载导航或车联网系统，通常都含gis终端，所以在上标注事故点，并语音播报事件信息，从而让能提供救助的人准备救援。
53.同时，不愿意提供社会救助的司乘人员知道前方有比较严重的事故，故而变更原先设定的道路，为缓解拥堵起到作用，从而缩短应急车辆到场时间。
54.关于c-v2x系统与车联网系统，因为前者是中国特别设计的车联网体系，与传统意义车联网系统不太相同，故而均列出，以差分中国标准或非中国的车联网系统。
55.而对于车路通信系统，国外与中国的从业者的思路也不同，故而作为求救对象或警示前方事故，从而使后续被或将被影响车辆等可以及早决策，规避拥堵与二次事故。
56.通过交通服务系统，可将求救信息发送机动车辆与驾驶员，而通过无线的基站或接入点等，可将求救信息发送智能终端如手机等，从而通知事故点附近的人。
57.s04即协同应急系统可以是公共应急系统、交通服务系统或移动运营商系统的部
分，也可以是独立提供服务的系统。
58.协同应急系统是基于紧急呼叫单元的位置信息(复合位置信息，含卫星定位、基站定位、ip等)获取位置，特别在隧道等易发生事故区域且还无定位，能有应急的助力，这是目前144r忽视技术领域。
59.为了更加明确的阐述紧急呼叫单元，以下根据以紧急呼叫单元的系统图为依托，阐述其工作方式与实现手段。
60.需要注意的是公共应急系统，如含交警应急、公安应急、消防应急、医疗救护、城市应急等，这些机构与系统中，在收到事件信息后，根据事件响应如道路封闭，如拥道优先等，需要通过将决策信息或控制指令发送给这些交通服务系统，然后交通服务系统响应，从而对路面车辆进行导流、限流等措施(实质对车辆及驾驶人员提供决策所依据的官方或法律支持的信息)。
61.图3是紧急呼叫单元的系统模块图，其中100为系统模块图中的感知、处理、接口、人机交互、通信等单元或者紧急求救的功能单元，而p01储能、供电单元，其中p01需要在机动车熄火、停电时，独立供电，保证紧急呼叫单元系统的工作，在机动车运行时被充电，同时对于储能如电池的管理。
62.在整个系统模块图中含传感单元、通信单元、接口单元、中央处理单元、存储单元以及人机交互用单元，含触发按键、音频播放、音频采集及视频采集等(音频单元在事件时也是人机交互中所需的重要传感单元)。
63.各单元通过电路连接至c01单元，向c01提供数据或c01控制各单元的工作，如初始化、控制、状态监测等。
64.其中c01为中央处理单元，含中央处理器(如单或多cpu或mcu)及相关外围电路以及包含程序运行，以处理各单元提供的数字信息，从而以运算、处理、控制、通信。
65.存储单元用于存储数据、程序等，也可含中央处理单元所需计算的存储；ss1定位传感器单元，含卫星定位模组及相关外围电路，用于获得用于位置计算的数据，在需要时，也可以用于提取卫星时间，用于对时或报文中精确时间的标注，或者紧急呼叫单元的系统时间校准。
66.ss2加速度传感器单元，当紧急呼叫单元在车中固定装配后，其可用于感知与水平的关系，从而用于获得车体的状态如判断车侧翻、倒翻等；同时该传感器还可以用于加速度变化的感知，特别是非正常情形或非正常方向的加速度陡然变化或保持，该单元含加速度传感器及外围电路，以获得数据并能向中央处理单元提供数据；其中，对于车体的状态如侧翻等，当然还可以用多组倾侧开关实现，根据检测不同方向倾斜的开关量判断车体状态是否正常或者已侧翻，倒翻等；所以车体状态感知除了可以用加速度传感器外，还可以用倾侧开关或类似传感电路实现，方法较多(本说明中的车体状态含其正常、倾斜、侧翻、倒翻等状态)。
67.ss3陀螺仪传感器单元，含外围电路与陀螺仪，用于感知剧烈角速度变化或与定位单元匹配，以利用惯性导航手段，辅助定位单元，特别隧道或卫星定位信号受干扰区域、无信号区域，通过对事件前一段时间的定位数据，比如5分钟，基于定位、时间、陀螺仪数据等，判断进入隧道后相对准确的位置(隧道中事故、起火等情形下，应急通常更困难)。
68.ss4是音频采集传感器单元，含外围电路与麦克丰或类似传感器如压电传感器，将
声波转换为电信号，一方面将用于人机交互，一方面可以用于撞击等超过较大分贝，或者撞击类特征声音的采集，同时如果在乘员能讲话时，也是与后台工作、协同介入的应急人员沟通的声音采集器；ss5为视频采集传感器单元，含摄像机与外围电路，提供对应与驾驶位或其它乘员位置的摄像机，在事故后，可开启，用于视频采集分析或编码，向应急协同平台发送或特定单位如应急单位的实时远程调用；当然车体多个位置也可布署，以了解事故时内外车体的情况。
69.ss6为温度传感器单元，含温度传感器及外围电路，可以敷设在车内，固定在机动车动力能源如电池组、油箱、或其它易于发热、燃烧的部位，用于感知该部位温度是否超标，比如车体内温度短期内从25度上升到50度，且是在突然停车后，显然是非正常情形下的升温。这类传感器可以是多个，线路考虑耐火的材料，从而实时获知温度，以对现场救援的人实时进行指导。
70.ss7为有害气体传感器单元，含气体传感器与外围电路，如对烟雾、具体的气体如二氧化碳、一氧化碳或车体内氧气等浓度的感知，用于监测各种车体内的情况；此外，国内外常有车内温度过高或氧气缺乏，导致人员死亡的案例，而紧急呼叫单元采用传感器感知并唤醒的电路后，则采用本说明书的方法或系统，呼叫周边人员、车辆管理者或拥有者或事件关联人予以解救车内被困的人。
71.ss8为水浸传感器单元，含水浸传感器、线缆及外围电路，多传感器安装在车体内或外不同位置，从而判断汽车落水或严重水浸，这也是常态的机动车落水后，如果救援不及时，则易于死亡，特别是校车、大巴等人员密集车辆落水，往往因救援不及时导致多人死亡。
72.i1为机动车车载接口单元，该单元含接口物理器件及必要的接口电路，用于与机动车车载单元接口，机动车车载单元通常是机动车总控单元，监测与管理汽车的各部件；机动车自身系统检出事故后及事故的属性，将数据通过i1，发送c01单元，用于触发下步功能执行；值得注意的是，如果与机动车车载单元通信与结束通信时，如双方采用协议握手方式，就可以判断出汽车在开启状态下的事故，或者事故导致机动车电路问题如或掉电、短路或者机动车在停驶状态下的事故，如自燃或车体内缺氧、温度升高等(车内需有耗氧的生物或者事件等，如被关的宠物、小孩)，从而判断、求救。
73.此外，当判断出需要求救时，则需要用通信单元与外界通信，从而通知相关能施与救援的人。
74.通信单元可含c1蜂窝网络通信单元，该单元可含3g、4g、5g等通信模组及外围电路，该单元功能是与蜂窝网络互联含数据通信功能，从而在事件时，通过c1向应急协同平台或所漫游的基站请求信息发布，以通知相对较小区域中的人救援；同时该单元也用于传输数据如车体内外的传感数据、音频数据与位置数据或远端调用车体内传感器数据如图像等，同时也可以被当作语音的主叫与被叫通信使用，以用于单工、双工通信。
75.c2为专用短程通信单元，含专用短程通信模组与外围电路，用于向周边v2v车辆通信，发送求救信息，也可向利用了这种通信技术的路侧通信设备及系统发送求救信息，该单元适用于采用专用短程通信应用于v2v或路侧通信的国家、区域；c3为wifi通信单元，含通信模组与外围电路，用于在wifi路网覆盖国家或区域，用于数据通信以及经过接入点的对终端的紧急求救广播。
76.c4为蓝牙通信单元，含蓝牙通信模组与外围电路，用于与采用蓝牙通信的路侧设
备以及驾驶员音频系统(见本发明人关于机动车事件的提示专利《一种提示、指导的方法、系统及机动车辆》)，在该专利中，可以基于本紧急呼叫单元，在判断事件发生，通过车内音频单元与驾驶员音频单元，语音指导事故人按照事故地交通法及安全最佳事件处置事故，包含车内指导与车外指导，内容含如“人离开车，布置警示装置，布置警示器的距离，测距等”，这样在98％的机动车交通事件(故障停车、轻微剐蹭等情形下)，指导车上人员按照法律、安全最佳实践执行，而不是如今情况，事故人情绪问题、经验问题、应激反应问题等，导致大量二次事故以及故障停车、轻微剐蹭，最终演变为重大事故、多人死伤事故。
77.c5为车路通信单元，这是不同国家采用的不同车路通信技术而采用的通信模块，含通信模组与外围电路，以向车路通信的系统发送求救信息，从而通知附近车辆。
78.sp1为音频播放单元，可含车内音频播放单元与机动车驾驶员用音频播放单元，含扬声器与外围电路，从而播放提示、语音双向通信时对方的声音。在通过机动车驾驶员音频播放时，可以是采用骨传导方式而不仅是声波方式。
79.在车辆水浸情形下分有人在车内情形与车内无人情形，在有人情形如车掉入水库、河流，则采用sp1播放，语音指导当事人在车内利用工具破窗或开门自救(落水后自救的最佳实践)，因每种车有自己设计特征，故而每车型有对应特征的提示信息，提示信息比如含利用车椅靠背枕头铁杆的尖头，在车窗玻璃角去撬玻璃从而破窗；而车内无人情形下，一般通知车主(如地下室进水问题，路面雨水积水陡涨或机动车停车不当导致滑入河道湖泊中等)。
80.在系统内因事件属性主动触发的音频内容(如机动车落水)可以存放在存储中，也可以是音频播放单元的组件，如预置好的音频芯片，触发后即根据中央控制单元给的编码或指令播放对应语音指导信息(针对车内有人情形)，当然也可以被后台人工直接指导。
81.而触发按键可含sos键，在sp1提示时，可直接按下(如果驾驶员或乘员都有行为能力或被卡困时使用)，或类似泥石流、沙土塌方这类事故时，传感器并不能实时判别，但乘员认为无法脱困直接按下，以增加求生可能。
82.触发按键也可含取消sos紧急呼叫的功能，以防止误触发后造成的多应急或交通系统的误动作；紧急呼叫单元是判断事件发生、触发求救前，先会通过sp1发出语音提示，指导事故人按键或者敲击或者行为表达(肢体或运动行为表达感知需要图像感知传感单元如摄像机，来识别摇头、眨眼睛或其它行为)，在无回应时，如死亡或昏迷时，则在设定时间过后可直接触发求救；当然在无回应时如果含视频采集功能时，也可由紧急呼叫单元识别或后台通过图像确认，由紧急呼叫单元或后台触发社会求救请求及公共应急的请求(所述后台含应急协同系统)，因为如果遇到事故人没有受伤，在提示阶段就撤出车外等情形或乘员直接从车窗因事故飞出，自然也无回应，则易于造成误求救呼叫，干扰周边群众正常生活。
83.因为涉及事故时，是否得到实时社会救援非常重要，特别含重伤或危化品以及应急窗口特别短的事故后导致燃烧的情形，这种情况下政府应急力量通常无法到场，在机会窗中争取时间就可以挽救生命，随着广泛使用新能源车的情形下，无论事故燃烧还是自燃，数量增加较快，所以需要采用多重传感监测的紧急求救。
84.此外，需要注意的是，在危化品车辆中，气体传感、温度传感、针对性的液体属性传感(如盐酸、硫酸泄露、)等传感器要安装在危化品的周边，多点敷设，从而在事故后，即便单个电路、联线、线路损坏，还能检测、探知泄露、燃烧等，此外还需要对罐体内压力、液位等实
时检测，从而更全面视角的报道；此外，结合本技术人在先的危化品车辆事故处置的技术中(《一种道路运输事件应急的方法及系统》)，因采用了动态关联，所以结合所拉货物的数量、品类，现场传感器的信息，在检出事故发生，且还不至于对救援者产生生命安全时，可以基于动态关联的数据，应急协同系统中的应急策略，指导现场附近的人员，救出车内被困、昏迷或死亡的司机，以便在事故肥尾前，帮助司机、押运员等人员挽救其生命等。
85.与普通常识认为报警求救就是一次性行为不同，本说明书中，紧急呼叫单元会持续性更新现场的传感数据，并由应急协同平台按照事件属性对应的处置逻辑处理并持续发送相关响应人或单位，如p01、p0，通过这种实时检测，容易判断燃烧或爆炸前，让救援人员撤离，同时也能自行判断车体内外情况。
86.此外，协同应急系统中还含协同共享资源，可以直接因事件接入事故人的监管人或家人，协助救援或督促救援，规避事件发生后，一些流程导致信息缺少，无法事件确认情形，见本发明人关于救援协同的专利《一种隐蔽的基于智能终端/手机及其附属或关联设备的求救方法》，这是因为在事件中，事故人可能无法说话、昏迷时，其家人或监管人根据掌握的信息，可以提供救援确认的信息或者可能更清楚事故发生的可能或外人不掌握知的信息，而该类信息非常有助于救援(如药物过敏、血型、既往病史等，救护时需立即掌握的信息)，在校车应急事件中，除了校方、车管理方还有教育主管单位、学生家长等，都在此列。
87.紧急呼叫单元含传感器单元、无线通信单元、中央处理单元、存储单元、音频播放单元，通过传感器单元或/和机动车车载单元感知事件，并通过中央处理单元计算、处理并确认事件，触发语音提示，指导车内人员处置事件或紧急求救确认，并紧急求救；对于所述事件是应急窗口短的事件，通过无线通信单元，经过协同应急系统通知事故地交通服务系统与公共应急系统，以及通过移动蜂窝网络或wifi网络，在所述无线单元连接的基站或接入点中群发或广播求救信息；所述求救信息通过无线通信单元，持续经协同应急单元通知应急响应者；所述应急窗口短的事件含机动车内人员不能自行脱困的事件，含起火、落水事件、高速事故等；如果所述紧急呼叫单元装配在机动车辆上时，如果机动车的车载单元不可以连接(如老式车辆)，应急呼救单元依靠自身传感器感知事件。
88.紧急呼叫单元可含传感器唤醒功能，当机动车停止行驶时，当一项或多项传感器超过阀值后唤醒整个系统，这是针对车在不行驶时，如自燃、车内有生物(人或动物)，车内气体、温度有害、地库或停车环境水浸等感知，这种情形下，自燃或车辆内有人或动物时，不但要通知车主、车管理单位，而且要通知周边消防等单位，予以火场处置以及人员动物的救助，如果车内人员或动物反应剧烈时，需通知周边人员救助、破窗指导，也就是通过传感器唤醒，来监测机动车可能的需要处置的事件以及救助响应。
89.所述机动车含且不限于客车、公交车、危化品车辆、校车、与普通机动车等。
90.所述紧急呼叫单元可通过应急协同平台自动呼叫被困者的亲属、监管人，介入应急呼叫或经过应急协同，向应急响应者提供信息或督促应急响应者。
91.需要指出，es04协同应急系统，紧急呼叫单元通过无线网与其连接，协同应急系统可以是独立服务系统，也可以是某主要公共应急系统的部分，从访问逻辑含网络接入模块，通常是由路由器、防火墙等设备构成，与internet等外部网络互联，紧急呼叫单元通过无线网络连接应急系统时，首先要通过网络接入模块，之后在数据访问/接口模块建立数字连接，提供数据或请求对应的服务，数据访问/接口模块通过通信中间件将所紧急呼叫单元要
求的服务请求与提供的数据按照业务设定，分别予以存储、处理或者通知对应资源提供服务(如协同资源)，其中，与通信中间件互联的含数据库模块、gis模块、事件处理模逻辑块、协同模块、运算、处理模块等；通信中间件还在各业务模块工作时作为数据交换之用。
92.当紧急呼叫单元触发后将与es04连接，提供采集的数据，含位置、传感器的数据如温度、车体的状态是侧翻、以及求救者状态(事故人员自主触发还是系统达到时长后，车内人员无反应式触发)，如果含视频传感器，可以同时包含被监控位置的图像。
93.在紧急呼叫单元通过所联基站或接入点群发或广播求救信息时，协同应急系统基于应急呼叫单元提供的位置数据，基于gis系统，形成位置信息的连接，并反馈给紧急呼叫单元，紧急呼叫单元将请求该基站或无线接入点发送求救信息，该信息就含协同应急系统所处理后的信息及连接，通过基站收到求救信息的终端的使用者点击求救连接(当然直接可以弹屏)，即访问了协同应急系统中关于该事件在地图(gis)的位置，对应车型的关键注意事项，需要携带的工具、现在车的事故情况，甚至可以含车体内的照片，以让收到群发或广播的人迅速行动，增大被困者的被救可能。
94.此外，事故点附近有可以拍照者但无能力救助者，也可以拍照片，通过进入的界面上传，在该事件应急的参与者中都可以看到。
95.对于车辆坠河等，轻的车通常还顺水流走，所以持续的数据更新就特别重要，这是应急的前提，此外，工具建议就是能漂浮的工具，绳索、船等，否则即便消防力量到场，应急力量也不能泅渡与救人。
96.当产生面向周边社会公众发出社会求救时，事件通常都比较严重、紧急，所以通过网络连接事故地所在的公共应急单位，并通知对应应急中心与事故点的应急单位(注，应急呼叫中心与事故出勤通常非一个单位)，如一方面通知119(呼叫中心)，另一方面并行通知了该地事故点附近的消防队/消防所，从而规避现流程浪费时间的缺陷问题。
97.对于无法数字连接的公共应急单位，协同应急系统可以采用电话呼叫，告知公共应急单位事件号，应急单位在协同应急系统访问该事件号即可实时掌握现场的情况，此外还可打数字电话系统如值班手机等，同时将连接发送该值班手机从而数字连接。
98.所以有效的方式是与公共应急系统数字连接，数字报警求救，而效率比较低的方式现有电话、语音，而效率更低的就是unece r144的方式，因为无数据更新，无现场状态的信息，是对救援所需信息与救援效果而言最差的一种情况。
99.关于应急协同系统的更多技术描述可以见本技术人/发明人关于面向场景的通信系统及其他i2x技术族的专利(《一种面向场景及内容的新型移动通信系统》)。
100.当然应急协同系统还与移动服务商、交通服务系统等数字连接，实时提供数据或特定的请求，如，经过移动服务商的群发请求。
101.关于前文所述的基于基站的群发或基于接入点的广播，实现的方法如下：首先，当移动蜂窝通信的模组(含模组的终端如手机或车载单元)在移动漫游时，都可以获得如cid(基站编号)、lac(位置区域码)等基站的唯一信息，所以在请求在该基站发送求救群发具备明确的基站信息与请求发送群发求救信息的具体基站(关于基站的群发技术、广播技术，见各大通信制造商群发、广播专利及电联等相关标准)。
102.紧急呼叫单元在机动车行驶时，会不停的在基站之间漫游，当机动车事故时，其漫游到某基站，紧急呼叫单元可以获知基站的信息如cid，lac等，而同由该基站服务的智能终
端或者手机的用户，如果收到群发的求救信息，理论上则会是事故点附近数百米范围内，如果在求救信息的提示下，携带救援工具，则新能源车中被困人员则有很大可能在如电池爆炸前被救出，而如果伤者坐等公共救援体系，则通常无法在事故后几十秒到2分钟内赶到，所以最近系列新能源车被困人员事故中，均是附近群众社会救援所致，明显的减少了伤亡。
103.所以在本公开中，紧急呼叫单元(e01)根据车辆电子设备或紧急呼叫单元的传感器，感知事件信息，并由所述紧急呼叫单元判断事件发生时或车辆成员按下触发按键，将事件发生位置及采集信息发送es04协同应急系统，并由协同应急系统处理后，将形成的报文发送 e01紧急呼叫单元，紧急呼叫单元请求所连接的基站p03向漫游在该基站上的智能终端或手机发送求救信息。
104.求救信息可以是短信形式，但其含url(用户资源连接链)，收到短信的用户点击url，即可了解到求救位置(地图上的标注)、车类型\车型、针对该车型的处置技巧、安全建议、以及需要的工具。求救信息也可以是交互式网页，智能终端或者手机收到群发的信息后，终端直接进入交互页面；当然求救信息也可以是富媒体信息(如中国5g的新创的信息模式)，但也需要用户点击进入交互界面(如点击图、文、按键，进入交互页面),如果未来手机与移动运营商是含提示服务时，则信息也可以是提示服务(notify as services)的形式群发。
105.紧急呼叫单元按照基站或蜂窝通信协议，向基站发起请求，这样协同应急系统生成的信息与访问该求救事件在协同应急系统中的资源连接就可以向响应人员发送。
106.在这种方式下，效率非常快，但缺陷是按照不同国家对基站群发的要求，显然缺乏信息内容监管再行群发的信息安全约束，所以可以采用图5方式。
107.在图5中，紧急呼叫单元(e01)根据车辆电子设备或紧急呼叫单元的传感器，感知事件信息，并由所述紧急呼叫单元判断事件发生时或车辆成员按下触发按键，将事件发生位置、采集信息及基站信息发送es04协同应急系统，并由协同应急系统计算、处理后，将形成的报文发送p02移动运营商系统，移动运营商系统根据报文中的基站信息(如cid，lac等)，控制\指令所述紧急呼叫单元所漫游的基站群发求救信息，求救信息如上所述。这样移动运营商系统或流程就可以对求救报文进行监督或处理，当然，在基站不能按照终端直接请求群发求救报文时，也需要采用图5的方法。
108.所以采用图5或图4的方法，对于时间窗口特别短的应急事件如新能源车、危化品车量等，对于快速响应救人有非常高的效率，目前业界并无此类技术应用到应急。
109.此外需要注意，现有手机或智能终端具备以下功能后，应急效果会更好，如求救信息上有特定特征字段，如@110、@122(仅是用于说明)，当基站所发送信息特定位置含标志特征字段后，手机或智能终端收到信息含这个字段后，自动调整音量至较大或最大，调整震动，目的是提醒手机或终端用户注意，此外，收到这类含特征的信息后，终端或手机直接自动进入应急协同界面(求救信息里的url)，这样以增大求救者存活的可能；而对于车载类终端，则是根据特征数据，标注在车载终端的地图服务上，并计算与当前的距离，以及语音通知前方事故车状态及需要的应急工具与注意事项等以及与当前的距离，让司乘人员在行驶中即准备；也就是为了应急的效率，在各导航服务终端、手机终端，智能终端，要在类似电联或中国的信通院下制定社会救助的标准，在终端中应用，不但在本说明书中可以用于救车内事故者，也可以用于其他社会救援需求，如心脑血管患者突然发病等。
110.关于前文所述的交互式页面，这是因为事件是个持续发生的过程，所以被群发到的人可以在交互式页面看到基于gis系统生成的含地图的事件位置信息(注意，gps的定位信息，对于普通社会救援者是无效的通知信息)；事件状态信息，如新能源车能源单元温度已经达到150度等，或某关键位置已经起火(如温度超过100度，同时还有烟雾等)，以及社会救援的工具提醒，如破窗工具、消防工具(消防斧、灭火器)、救护器具如救护包等，愿意的施救者在看到信息后，可点击交互页面上自己将用于救援的工具，则系统会标记数量，从而其它被群发并响应的人可以基于工具信息，准备其它缺失的工具，比如绳索等。而比如是落水时，如果车体是漂流的，则其位置、移动轨迹等均在交互网页显示，从而救援者根据桥、涵等易于救援位置施救，同时准备绳、浮具、破窗、破拆工具等，如果车体下沉，至少在定位信号受干扰前有准确的持续的定位信息，便于搜救。
111.但是因为是社会救援，施救者多是普通好心人，所以交互页面中根据事故车型(紧急呼叫单元与车型、车牌等绑定)，生成建议，例如开门技巧、破窗技巧、判断风险的技巧以及提醒，如电池组温度超过摄氏150度或者多处明火时，就要建议施救者注意个人安全，或停止救援、远离现场，远距拍照、视频，作为临时的事件采集者，以对官方应急单位了解现场事态(紧急呼叫单元因与车装备，所以车型，甚至车牌、车所有人等均可以绑定)。
112.此外，交互页面还可上传照片、以及现场视频，这样通过应急协同单元，公共应急单位一方面了解现场，同时可以指挥救援群众，也就是形成了专业人员指挥，现场有能力百姓的应急执行，从而让被困者有机会在短的时间脱险。
113.但在呼叫呼救信息群发中，所发送的信息在危化品运输车辆与普通车辆还是有区别的，普通机动车司乘被卡在车内时、昏迷时，需要社会力量帮助，而危化品需要根据“动态关联”的信息与传感器收集数据做判断，比如氯气泄露情形，是建议附近百姓撤离而不是救援或在较远不受安全影响的地方拍摄现场，让应急单位多视角了解现场情形，所以危险化工车辆，偏向于通知周边手机、智能终端用户避险，而普通机动车，偏向于社会救助，帮助脱困，所以目的不同，功能不同效果不同。
114.本说明书中公开了针对应急窗口窄、短这类机动车事件中，人员被困的紧急求救方法、系统、紧急单元，作为i2x技术族中，针对司乘人员被困、昏迷等情形下的紧急呼叫、呼救，以让业界现在的难点问题，传统救援技术的思维惯式、技术偏见导致的救援缺陷问题得以解决，从而提升机动车的总体的安全性。
115.在机动车中，安装紧急呼叫单元，在检出事故后，在提示与人机交互后，发出呼叫、呼救信息，并实时向应急协同系统更新车体中的数据，以便于救助决策。
116.本说明书中，包含了一种紧急呼叫的方法，其特征在于，包括：通过车辆电子设备或/和紧急呼叫单元的传感器，感知事故事件，并由所述紧急呼叫单元判断事件并触发求救；应急协同系统与所述紧急呼叫单元数据互联，并将所述紧急呼叫单元提供的数据计算、处理，形成求救信息，并发送至交通服务系统及公共应急系统；此外，还通过所述紧急呼叫单元所连接的基站或无线接入点,群发或广播所述求救信息至事故现场附近的人或车辆驾驶员的手机或智能终端。
117.所述的一种紧急呼叫的方法，其特征在于：其中所述求救信息还通过车辆对车辆无线通信技术，发送至与所述紧急呼叫单元通信所互联车辆的终端。
118.所述的一种紧急呼叫的方法，其特征在于：当群发需要移动运营商管控时，所述应
急协同系统除发送求救信息外，还发送所述紧急呼叫单元所漫游基站的唯一编码信息。
119.所述的一种紧急呼叫的方法，其特征在于：所述求救信息含url，求救响应的者进入 url后，实时获知事故车的传感数据、救援指导、以及响应者互相协同。
120.所述的一种紧急呼叫的方法，其特征在于：所述紧急呼叫单元判断事件发生后，包含通过人机交互步骤，由车内人员确认求救或紧急呼叫单元自动确认求救。
121.本说明书中还包含一种紧急呼叫单元，其特征在于，包括：所述紧急呼叫单元装备在机动车辆上；含传感器单元、无线通信单元、中央处理单元、存储单元、音频播放单元；通过传感器单元或/和机动车车载单元感知事件；通过中央处理单元计算、处理并确认事件；如果事件确认后，含语音提示流程，指导车内人员处置事件；如果求救确认后即触发求救；所述求救的方式包含：通过无线通信单元，经过协同应急系统通知事故地交通服务系统与公共应急系统；通过移动蜂窝网络或无线接入点，在所述无线单元连接的基站或无线接入点中群发或广播求救信息。
122.所述的一种紧急呼叫单元，其特征在于，包括：所述求救确认含人机交互方式或视频方式。
123.所述的一种紧急呼叫单元，其特征在于，包括：机动车停驶时，通过传感器唤醒电路，监测机动车的状态，根据传感器数据，判断并启动求救或通知车主。
124.所述的一种紧急呼叫单元，其特征在于，包括：所述应急呼叫单元在所述事件确认后，解锁车门、车窗。
125.本说明书一种紧急呼叫系统，其特征在于包括：含协同应急系统及所述紧急呼叫单元的任意一项特征，应用紧急呼叫方法的任意一项特征，感知事件并触发求救。
126.此外还含一种机动车辆，其使用了所述的紧急呼叫单元，或使用了紧急呼叫方法，或者在紧急呼叫系统的服务下，检出事件，并应急。
127.此外，需要注意的是，当事件生成的url是约定方式时，紧急呼叫单元可直接向基站等发送该约定的url，这样被通知者可以直接访问url，而紧急呼叫单元无需等到后台计算后再反馈给紧急呼叫单元就可以发送群发请求，这样的缺陷是，若被通知者访问太迅速，有可能完整信息还没生成(假设在较复杂逻辑下)。
128.此外紧急呼叫单元还可以含方向传感器，如与车头方向固定设置，这样在加速度、定位、gis、方向传感器等的组合数据下，可以判定事故方向(如果事故占道)，如果在亚米级别定位芯片的数据下，可以根据车辆尺寸估算出在该点的较准确占道信息，从而对来往车辆该避让的车道有提前告知的信息采集功能，从而对避免二次事故起一定作用。
129.在校车这种车辆事故时，现有管理系统是无法应对起火、落水等紧急情形，而后台管理员/司机/看护员也是基于一一通知各应急单位，且因为车内司机与看护员通常在车前位置，一旦车头部严重事故两位大人重伤或死亡时，车体内根本无大人能起到自救与求救作用，所以紧急呼叫单元要根据传感信息及时判断并语音自动指导、后台监管人员直接介入指导，从而安慰惊慌的孩子而不是完全被动等救援，而周边社会群众被通知，根据传感器、摄像机判断的落水、起火、翻车等情形判断携带工具，紧急响应，从而避免因落水、起火、救援不及时等造成的重、大事故；针对校车，紧急呼叫单元可以配置两套或多套，以分布在车体内不同区域以冗余。
130.此外，校车的儿童死亡事件中，含因看护人员与司机遗留孩子在车内，最终因热致
死，所以紧急呼叫单元也可以规避该情况的产生。
131.此外，紧急呼叫单元也可以与校车管理系统数据互联，从而获得车内人数，特别是事故时，现场混乱，社会救援者能不遗留孩子在车内，所以参与救援的人在协同界面就可以掌握将被救援者的数量，从而规避校车落水时遗留孩子在车体的情况。
132.此外，在公交、大巴等车辆落水、起火时，附近百姓的及时社会救援、破窗、破拆、众多的救援群众帮助下等，可以直接降低死亡数量与重伤数量，而一味等公共救援体系应急时，事故容易因救援迟滞而恶化；此外，现有基于电话的应急呼叫系统、非并行的报警求救系统、各系统的内部流程时间，以及缺乏社会协同，会直接导致救援迟滞。
133.本说明书中技术，是对现有技术标准以及行业技术的偏见的破解，从而解决当前无解的窄窗口车辆事故后应急的问题，本领域技术人员通过上述说明书以及说明书中本发明人提到的其它在说明书中的技术，就可以实现本方法、系统、紧急呼叫单元以及用于装备使用这些方法、系统的机动车辆。