CN117651980A - 移动性服务基础服务器、移动性服务提供系统、车辆访问控制方法、程序 - Google Patents

Abstract

车辆侧单元(110)具有车辆控制部(130)。车辆控制部在设置于服务侧单元(120)的接口部(122)受理了针对车辆的访问请求的情况下，通过进行与搭载于对象车辆的车载机(2)的无线通信来执行对对象车辆的访问，上述对象车辆是成为访问对象的车辆。车辆控制部对于在与车载机之间收发的控制指示执行中继控制。

Description

移动性服务基础服务器、移动性服务提供系统、车辆访问控制 方法、程序

相关申请的交叉引用

本国际申请主张基于在2021年7月2日向日本专利局申请的日本专利申请第2021-110904号的优先权，通过参照将其全部内容引用到本国际申请。

技术领域

本公开涉及提供移动性服务的技术。

背景技术

专利文献1中记载了通过从车辆收集车辆数据来在虚拟空间再现现实世界的车辆的状态的数字双模拟。

专利文献1：日本特开2019-153291号公报。

研究了接受移动性服务的扩展，经由系统访问车辆，实现利用车辆所具有的功能的各种应用程序。

发明内容

本公开提供使移动性服务所涉及的车辆访问的可靠性提高的技术。

本公开的一方式是移动性服务基础服务器。移动性服务基础服务器具备车辆侧单元和服务侧单元。

车辆侧单元具有存储多个阴影的第一数据库，上述阴影基于从搭载于车辆的车载机提供的车辆数据，按每个车辆生成，表示特定的时刻下的车辆的状态。

服务侧单元具有第二数据库以及接口部。第二数据库存储与积蓄于第一数据库的阴影分别对应，具有检索阴影所使用的信息的索引。接口部构成为受理来自外部的访问请求。

车辆侧单元还具备车辆控制部，该车辆控制部构成为在接口部受理了针对车辆的访问请求的情况下，通过进行与搭载于对象车辆的车载机的无线通信来执行对对象车辆的访问，上述对象车辆是成为访问的对象的车辆。车辆控制部构成为对于在与车载机之间收发的控制指示执行中继控制。

根据这样的构成，能够使车辆访问的可靠性提高。

本公开的一方式是移动性服务提供系统。移动性服务提供系统具备搭载于车辆的车载机和上述的移动性服务基础服务器。

本公开的一方式是车辆访问控制方法。应用了车辆访问控制方法的移动性服务基础服务器具备第一数据库、第二数据库以及接口部。

在车辆访问控制方法中，在接口部受理了针对车辆的访问请求的情况下，通过进行与搭载于对象车辆的车载机的无线通信来执行对对象车辆的访问，上述对象车辆是成为访问的对象的车辆。在对对象车辆的访问中，对于在与车载机之间收发的控制指示执行中继控制。

本公开的一方式是程序。执行程序的计算机与第一数据库、第二数据库、接口部一起构成移动性服务基础服务器。

程序使计算机作为车辆控制部发挥作用。车辆控制部构成为在接口部受理了针对车辆的访问请求的情况下，通过进行与搭载于对象车辆的车载机的无线通信来执行对对象车辆的访问，上述对象车辆是成为访问的对象的车辆。另外，车辆控制部构成为对于在对对象车辆的访问中在与车载机之间收发的控制指示执行中继控制。

附图说明

图1是表示移动性IoT系统的构成的框图。

图2是表示边缘装置的构成的框图。

图3是表示边缘装置的功能性构成的功能框图。

图4是表示帧的构成的图。

图5是表示车辆数据转换表的构成的图。

图6是表示标准化车辆数据的第一层和数据格式的图。

图7是表示标准化车辆数据的构成的图。

图8是表示标准化车辆数据的作成顺序的序列图。

图9是表示数据发送定时的时序图。

图10是表示管理中心的构成的框图。

图11是表示管理中心的功能性构成的功能框图。

图12是表示移动性GW以及数据管理部的功能性构成的功能框图。

图13是表示阴影的构成的图。

图14是表示最新索引的构成的图。

图15是表示索引的构成的图。

图16是表示授权信息存储部所具有的授权对象数据库的构成的图。

图17是表示授权信息存储部所具有的授权级别数据库的构成的图。

图18是表示API提供部的动作的序列图。

图19是表示数据获取请求的指定信息以及阴影访问请求的构成的图。

图20是区域指定的指定方法的说明图。

图21是索引获取部执行的阴影列表生成处理的流程图。

图22是表示利用了数据获取API的数据获取的步骤的序列图。

图23是表示车辆控制请求的指定信息的构成的图。

图24是表示受理了车辆控制请求的情况下的典型的动作的序列图。

图25是表示搭载车辆控制请求所涉及的车辆控制部以及边缘装置的车辆的构成的图。

图26是表示对控制历史存储部的登记内容的图。

图27是受理部执行的受理处理的流程图。

图28是在受理处理中执行的顺序处理的流程图。

图29是在受理处理中执行的唤醒处理的流程图。

图30是在受理处理中执行的优先处理的流程图。

图31是发送管理部执行的发送侧处理的流程图。

图32是接收管理部执行的接收侧处理的流程图。

图33是表示成为车辆控制请求的对象的车辆的电源状态接通的情况下的动作的序列图。

图34是表示没有从车辆的针对控制指示的响应的情况下的动作的序列图。

图35是表示成为车辆控制请求的对象的车辆的电源状态断开的情况下的动作的序列图。

图36是表示搭载于车辆的ECU的连接状态的框图。

具体实施方式

以下，与附图一起对本公开的实施方式进行说明。

[1.系统概要]

如图1所示，本实施方式的移动性IoT系统1具备多个边缘装置2、管理中心3、以及服务提供服务器4。IoT是Internet of Things(物联网)的缩写。

边缘装置2搭载于车辆，具有经由广域无线通信网NW与管理中心3进行数据通信的功能。

管理中心3是管理移动性IoT系统1的装置。管理中心3具有经由广域无线通信网NW在与多个边缘装置2以及服务提供服务器4之间进行数据通信的功能。

服务提供服务器4例如是为了提供管理车辆的运行的服务而设置的服务器。此外，移动性IoT系统1也可以具备服务内容相互不同的多个服务提供服务器4。服务提供服务器4既可以由内部配置(on-premises)构成，也可以由云构成。另外，服务提供服务器4也可构成为在物理上与管理中心3相同的服务器。

[2.边缘装置]

[2-1.装置构成]

如图2所示，边缘装置2具备微型计算机11、车辆接口(以下，车辆I/F)12、通信部13、以及存储部14。

微型计算机11具备第一核心21、第二核心22、ROM23、RAM24、闪存25、输入输出部26以及总线27。

微型计算机11的各种功能通过第一核心21以及第二核心22执行储存于非过渡性实体记录介质的程序而实现。在该例中，ROM23相当于储存了程序的非过渡性实体记录介质。另外，通过执行该程序，来执行与程序对应的方法。

此外，也可以通过一个或者多个IC等以硬件的方式构成第一核心21以及第二核心22执行的功能的一部分或者全部。

闪存25是能够进行数据改写的非易失性存储器。闪存25具备储存后述的标准化车辆数据的标准化车辆数据储存部25a。

输入输出部26是用于在微型计算机11的外部与第一核心21以及第二核心22之间进行数据的输入输出的电路。

总线27将第一核心21、第二核心22、ROM23、RAM24、闪存25以及输入输出部26连接为能够相互进行数据输入输出。

车辆I/F12是输入输出电路，该输入输出电路用于在与搭载于车辆的电子控制装置以及传感器等之间进行信号的输入输出。

车辆I/F12具备电源电压输入端口、通用输入输出端口、CAN通信端口以及以太网通信端口等。CAN通信端口是用于根据CAN通信协议进行数据的收发的端口。以太网通信端口是用于基于以太网通信协议进行数据的收发的端口。CAN是Controller Area Network(控制器局域网)的缩写。CAN是注册商标。以太网是注册商标。

在CAN通信端口以及以太网通信端口连接有搭载于车辆的其他的电子控制装置。边缘装置2能够在与其他的电子控制装置之间进行通信帧的收发。

通信部13经由广域无线通信网NW与管理中心3进行数据通信。

存储部14是用于存储各种数据的存储装置。

如图36所示，在车辆搭载有一个ECU210、多个ECU220、多个ECU230、车外通信装置240、以及车内通信网250。ECU是Electronic Control Unit(电子控制单元)的缩写。

ECU210通过总括多个ECU220而实现取得了作为车辆整体的协作的控制。

ECU220按通过车辆中的功能划分的每个域设置，主要执行存在于该域内的多个ECU230的控制。各ECU220经由分别独立地设置的下层网络(例如，CAN)与下属的ECU230连接。ECU220具有统一地管理针对下属的ECU230的访问权限等进行利用者的认证等的功能。域例如是动力传动系、车身、底盘以及驾驶舱等。

与属于动力传动系的域的ECU220连接的ECU230例如包含控制发动机的ECU230、控制马达的ECU230、以及控制蓄电池的ECU230等。

与属于车身的域的ECU220连接的ECU230例如包含控制空调的ECU230、以及控制门的ECU230等。

与属于底盘域的ECU220连接的ECU230例如包含控制制动器的ECU230、以及控制转向的ECU230等。

与属于驾驶舱的域的ECU220连接的ECU230例如包含控制仪表以及导航的显示的ECU230、以及控制由车辆的乘员操作的输入装置的ECU230等。

车外通信装置240经由广域无线通信网NW在与车辆外的通信装置(例如，云服务器)之间进行数据通信。

车内通信网250具备CAN FD和以太网。CAN FD是CAN with Flexible Data Rate(具有灵活数据速率的CAN)的缩写。CAN FD将ECU210和各ECU220以及车外通信装置240通过总线连接。以太网将ECU210与各ECU220以及车外通信装置240之间分别独立地连接。

ECU210是以具备CPU210a、ROM210b以及RAM210c等的微型计算机为中心构成的电子控制装置。微型计算机的各种功能通过CPU210a执行储存于非过渡性实体记录介质的程序而实现。在该例中，ROM210b相当于储存了程序的非过渡性实体记录介质。另外，通过该程序的执行，而执行了与程序对应的方法。此外，也可以通过一个或者多个IC等以硬件的方式构成CPU210a执行的功能的一部分或者全部。另外，构成ECU210的微型计算机的数量可以是一个也可以是多个。

ECU220、ECU230以及车外通信装置240均与ECU210相同地，是以具备CPU、ROM以及RAM等的微型计算机为中心构成的电子控制装置。另外，构成ECU220、ECU230以及车外通信装置240的微型计算机的数量可以是一个也可以是多个。ECU220是总括1个以上的ECU230的ECU，ECU210是总括1个以上的ECU220或者总括包含车外通信装置240的车辆整体的ECU220、230的ECU。

边缘装置2与ECU210连接，以便能够在与ECU210之间进行数据通信。即，边缘装置2经由ECU210接收ECU210、220、230的信息。另外，边缘装置2向ECU210发送与车辆控制有关的请求，或者经由ECU210向ECU220、230发送与车辆控制有关的请求。

[2-2.功能构成]

如图3所示，边缘装置2具备第一单元101，作为通过第一核心21执行储存于ROM23的程序而实现的功能模块。边缘装置2具备第二单元102，作为通过第二核心22执行储存于ROM23的程序而实现的功能模块。

第一单元101具备实时操作系统(以下，RTOS)103和第一应用程序104。

第一应用程序104执行用于控制车辆的各种处理。第一应用程序104为了执行用于控制车辆的各种处理，而构成为能够访问闪存25的标准化车辆数据储存部25a参照标准化车辆数据。

RTOS103管理第一应用程序104，以便能够确保第一应用程序104的处理的实时性。

第二单元102具备通用操作系统(以下，GPOS)105和第二应用程序106。

第二应用程序106执行与由服务提供服务器4提供的服务相关的处理。第二应用程序16为了执行与服务相关的处理，而构成为能够访问闪存25的标准化车辆数据储存部25a参照标准化车辆数据。

GPOS105是为了使各种应用程序动作而搭载于边缘装置2的基本软件，管理第二应用程序106。

[2-3.数据收集处理]

对边缘装置2收集车辆数据并主动地发送至管理中心3的一系列处理进行说明。

首先，对车辆I/F12执行的处理进行说明。

车辆I/F12若接收通信帧，则基于接收到通信帧的通信端口，判定通信帧的通信协议。具体而言，车辆I/F12例如在CAN通信端口接收到通信帧的情况下，判定为接收到的通信帧的通信协议是CAN通信协议。另外，车辆I/F12例如在以太网通信端口接收到通信帧的情况下，判定为接收到的通信帧的通信协议是以太网通信协议。

而且，车辆I/F12基于通信帧的识别信息判定是否是成为边缘装置2中的处理对象的通信帧，在判定为是成为处理对象的通信帧的情况下，向第一单元101输出接收到的通信帧。

如图4所示，CAN帧由开始帧、仲裁字段、控制字段、数据字段、CRC字段、ACK字段以及结束帧构成。此外，冲裁字段由11比特或者29比特的标识符(即，ID)和1比特的RTR位构成。

另外，将CAN通信所使用的11比特的标识符称为CANID。CANID基于CAN帧所包含的数据的内容、CAN帧的发送源、以及CAN帧的发送目的地等预先设定。

数据字段由分别8比特(即1字节)的第一数据、第二数据、第三数据、第四数据、第五数据、第六数据、第七数据以及第八数据构成。以下，也将数据字段的第1～8数据分别称为CAN数据。

因此，车辆I/F12在接收到CAN帧的情况下，基于CANID判定是否是处理对象。

接下来，对第一单元101执行的处理进行说明。

第一单元101若获取从车辆I/F12输出的通信帧，则从通信帧提取识别信息和数据，作成由识别信息和数据构成的标准格式数据。第一单元101将作成的标准格式数据存储于闪存25。例如，第一单元101在获取了CAN帧的情况下，作成由CANID和第1～8数据构成的标准格式数据。

此外，第一单元101在包含与作成的标准格式数据相同的识别信息的标准格式数据已经存储于闪存25的情况下，通过覆盖该标准格式数据来更新标准格式数据。

接下来，对第二单元102执行的处理进行说明。

第二核心22从闪存25获取标准格式数据。

而且，第二核心22分割获取到的标准格式数据所包含的数据。例如，从CAN帧生成的标准格式数据由CANID和第1～8数据构成，所以第二核心22按1字节分割第1～第8数据，提取8个CAN数据。此外，第一单元101以及第二单元102的标准格式数据的写入以及读出也可以不使用闪存25而使用RAM24。

并且，第二核心22参照储存于ROM23的车辆数据转换表23a，将分割后的各提取数据转换为控制标签以及车辆数据。

车辆数据转换表23a具备正规化信息和语义化信息。

正规化信息是用于将提取数据正规化为不管车种以及车辆制造企业同一物理量都成为同一值的信息。

语义化信息是指用于使用被正规化的车辆数据转换为有意义的车辆数据的信息。以下，也将被正规化以及语义化的车辆数据称为加工数据，将被正规化以及语义化之前的车辆数据称为行数据。行数据例如指由CAN帧的数据字段表示的数据。

如图5所示，车辆数据转换表23a的正规化信息例如具备“CANID”、“ECU”、“位置”、“DLC”、“唯一标签”、“分辨率”、“偏移量”以及“单位”作为设定项目。

“ECU”是表示CAN帧的发送源的ECU的信息。例如，“ENG”表示是发动机ECU。

“位置”是表示数据字段内的CAN数据的位置的信息。“DLC”是表示数据长度的信息。DLC是Data Length Code(数据长度代码)的缩写。

“唯一标签”是表示控制标签的信息。例如，“ETHA”表示吸气温度，“NE1”表示发动机转速。“分辨率”是表示每1比特的数值的信息。

因此，通过“CANID”、“ECU”、“位置”、“DLC”以及“唯一标签”，从标准格式数据提取出与“唯一标签”对应的数据。并且，提取数据通过“分辨率”以及“偏移量”转换为被换算成由“单位”表示的值的车辆数据。

另外，车辆数据转换表23a的语义化信息例如图5所示，包含通过从控制标签为“SSA”的“转向操纵移动角度”减去控制标签为“SSAZ”的“转向操纵零点”来转换为“转向操纵角”的转换式。通过该转换式，从表示“转向操纵移动角度”的车辆数据和表示“转向操纵零点”的车辆数据转换为表示具有“从基准位置起的转向操纵量”这样的意义的“转向操纵角”的车辆数据。

第二核心22将转换后的车辆数据层级化并存储于闪存25。具体而言，第二核心22将转换后的车辆数据储存于设置于闪存25的标准化车辆数据储存部25a的对应区域。

标准化车辆数据储存部25a储存将车辆数据层级化而构成的标准化车辆数据。

标准化车辆数据按每个车辆(即，每个边缘装置2)作成，具有多个层级构造。在标准化车辆数据中，对于多个层级，分别设定1个或者多个项目。例如，如图6所示，标准化车辆数据具备“属性信息”、“传动系”、“能量”、“ADAS/AD”、“车身”、“多媒体”以及“其他”作为最上位的第一层级中设定的项目。ADAS是Advanced Driver Assistance System(高级驱动辅助系统)的缩写。AD是Autonomous Driving(自动驾驶)的缩写。“属性信息”、“传动系”以及“能量”等相当于类别。

另外，各车辆数据具备“唯一标签”、“ECU”、“数据类型”、“数据大小”、“数据值”以及“数据单位”作为项目。“唯一标签”以及“ECU”如上所述。“数据类型”、“数据大小”以及“数据单位”表示与由“数据值”所示的数值有关的类型、大小、单位。

如图7所示，标准化车辆数据除了第一层级以外，至少还具备第二层级以及第三层级。第二层级是第一层级的正下方的层级，第三层级是第二层级的正下方的层级。标准化车辆数据是在上述的正规化以及语义化的处理中设定的项目。标准化车辆数据具有被层级化的数据结构。

例如，作为的第一层级的项目的“属性信息”具备“车辆识别信息”、“车辆属性”、“变速器构成”以及“固件版本”等作为第二层级的项目。“车辆识别信息”是表示能够唯一地识别车辆的信息的类别名。“车辆属性”是表示车辆的种类的类别名。“变速器构成”是表示与变速器有关的信息的类别名。“固件版本”是表示与车辆的固件有关的信息的类别名。

另外，作为第一层级的项目的“传动系”是表示与动力传动系有关的信息的类别名。“传动系”具备“加速器踏板”、“发动机”以及“机油”等作为第二层级的项目。“加速器踏板”包含有加速器踏板的状态、开度等1个以上的车辆数据。“发动机”包含有发动机的状态、转速等1个以上的各个车辆数据。第二层级的项目也相当于类别。其他的第一层级的项目也相同。

另外，作为第一层级的项目的“能量”是表示与能量有关的信息的类别名。“能量”具备“蓄电池状态”、“蓄电池构成”以及“燃料”等作为第二层级的项目。

另外，作为第二层级的项目的“车辆识别信息”具备“车辆识别编号”、“车体编号”以及“车牌号码”作为第三层级的项目。第三层级的项目是1个以上的各个车辆数据，也称为项。换句话说，在标准化车辆数据的层级结构中，将最下层的项目称为项，将最下层以外的项目(即，具有下位层级的项目)称为类别。

另外，作为第二层级的项目的“车辆属性”具备“品牌名”、“型号”以及“制造年”等作为第三层级的项目。

另外，作为第二层级的项目的“变速器构成”具备“变速器种类”作为第三层级的项目。

例如，第二核心22在转换后的车辆数据的控制标签是“车辆识别信息”的情况下，在标准化车辆数据储存部25a中第一层级是“属性信息”并且第二层级是“车辆识别信息”并且第三层级是“车辆识别编号”的储存区域储存转换后的车辆数据。

“其他”例如也可以包含从搭载于车辆的GPS装置经由车辆I/F12获取的位置信息，即，纬度、经度、高度。

接下来，使用图8所示的序列图，对边缘装置2作成标准化车辆数据的顺序进行说明。

如箭头L11所示，若车辆I/F12从车辆获取车辆数据，则车辆I/F12如箭头L12所示，进行通信协议判定。并且，车辆I/F12如箭头L13所示，过滤不必要的车辆数据，如箭头L14所示，向第一单元101输出必要的车辆数据。

第一单元101若从车辆I/F12获取车辆数据，则如箭头L15所示，将车辆数据转换为标准格式，如箭头L16所示，将转换为标准格式的车辆数据存储至闪存25。

第二单元102若如箭头L17所示，从闪存25获取转换为标准格式的车辆数据，则如箭头L18所示，转换获取到的车辆数据。并且，第二单元102如箭头L19所示，将转换后的数据结构化来作成标准化车辆数据。

接下来，对边缘装置2执行的数据发送处理的步骤进行说明。

在属于标准化车辆数据的各车辆数据分别设定表示向管理中心3发送数据的定时的定时信息。定时信息根据数据变化的程度、数据的重要度等设定为越是频繁变化的数据，越是重要度高的数据，则周期越短。定时信息例如是500ms周期、2s周期、4s周期、30s周期、300s周期、12小时周期等。

第二核心22以发送单位时间(例如250ms)周期执行发送处理。

如图9所示，将以500ms周期发送的车辆数据亦即第一频度数据分成2组，按发送定时交替地发送。相同地，将以1s周期发送的车辆数据亦即第二频度数据分成2组或者4组，并将各组的数据以以不同的发送定时发送。换句话说，通过根据预先设定的发送时间表发送各车辆数据，来抑制许多的车辆数据的发送集中于相同的发送定时。另外，通过以与其特性对应的频度发送各车辆数据，来实现高效的发送。

[3.管理中心]

[3―1.装置构成]

如图10所示，管理中心3具备控制部31、通信部32、以及存储部33。

控制部31是以具备CPU41、ROM42以及RAM43等的微型计算机为中心构成的电子控制装置。微型计算机的各种功能通过CPU41执行储存于非过渡性实体记录介质的程序而实现。在该例中，ROM42相当于储存了程序的非过渡性实体记录介质。另外，通过该程序的执行，而执行了与程序对应的方法。此外，也可以通过一个或者多个IC等以硬件的方式构成CPU41执行的功能的一部分或者全部。另外，构成控制部31的微型计算机的数量既可以是一个也可以是多个。

通信部32经由广域无线通信网NW在与多个边缘装置2以及服务提供服务器4之间进行数据通信。此外，与边缘装置2的通信使用MQTT，该MQTT是发布/订阅的简单轻便的协议。MQTT是Message Queue Telemetry Transport(消息队列遥测传输)的缩写。

存储部33是用于存储各种数据的存储装置。

[3-2.功能构成]

如图11所示，管理中心3具备车辆侧单元110和服务侧单元120，作为通过CPU41执行储存于ROM42的程序而实现的功能模块。接近向车辆的访问的一侧的功能模块是车辆侧单元110，接近来自服务提供服务器4的访问的一侧的功能模块是服务侧单元120。这2个功能模块构成为松散耦合。

实现构成管理中心3的这些要素的方法不局限于软件，也可以使用一个或者多个硬件实现其一部分或者全部的要素。例如，在上述功能由作为硬件的电子电路实现的情况下，该电子电路也可以通过包括许多逻辑电路的数字电路、或者模拟电路、或者它们的组合实现。

车辆侧单元110具有管理向车辆的访问以及从车辆接收到的数据的功能。车辆侧单元110具备移动性网关(以下，移动性GW)111。移动性GW111除了向车辆中继向车辆的访问请求的功能以外，还具有管理从车辆接收到的数据的功能。

移动性GW111具备阴影管理部112和车辆控制部130。阴影管理部112具备管理收容按每个搭载边缘装置2的车辆设置的车辆数据的阴影114的功能。阴影114表示某个车辆的车辆数据组。阴影114基于从边缘装置2发送的标准化车辆数据生成。车辆控制部130具备根据来自服务提供服务器4的指示，经由边缘装置2，控制搭载该边缘装置2的车辆的功能。

服务侧单元120受理来自服务提供服务器4的请求，并且进行车辆数据的提供。服务侧单元120具备数据管理部121和API提供部122。API是Application ProgrammingInterface(应用编程接口)的缩写。

数据管理部121具备管理用于提供不依存于车辆的连接状态的变化的车辆访问的虚拟空间亦即数字双123的功能。数据管理部121管理向在车辆侧单元110管理的车辆数据的访问所需要的数据。

API提供部122是用于服务提供服务器4向移动性GW111以及数据管理部121访问的标准接口。API提供部122对于服务提供服务器4提供用于获取向车辆的访问、车辆数据的API。

[3-2-1.数据积蓄功能]

如图12所示，阴影管理部112具备阴影作成部115、阴影存储部113、最新索引作成部116、以及最新索引存储部117，作为实现积蓄从边缘装置2获取的车辆数据的功能的构成。

阴影作成部115从边缘装置2接收被结构化的标准化车辆数据。每次从边缘装置2发送车辆数据，阴影作成部115都将被发送的车辆数据覆盖到被结构化的标准化车辆数据的对应区域，来更新标准化车辆数据。阴影作成部115也可以接收被结构化的标准化车辆数据的一部分。阴影作成部115使用被更新的标准化车辆数据作成新的阴影114。阴影作成部115将作成的阴影114积蓄于阴影存储部113。阴影作成部115使用被更新的标准化车辆数据作成新的阴影114时，也可以赋予序列号等任意的信息存储至阴影存储部113。在阴影存储部113中，按每个车辆存储以时间序列作成的多个阴影114。换句话说，阴影114能够视为复制了搭载边缘装置2的车辆的某个时刻下的状态。

一个阴影114是某个车辆的规定时刻的车辆数据组，包括由图13所示的被标准化的数据结构表示的车辆数据组。此外，阴影作成部115经由通信部32接收被结构化的标准化车辆数据的定时根据车辆不同。新的阴影114的作成也可以对于全部车辆在相同的定时进行。阴影作成部115也可以对于全部车辆以恒定周期进行新的阴影114的作成。在阴影存储部113中，按每个车辆积蓄过去的阴影114。也可以依次删除经过了恒定期间的阴影114。

如图13所示，阴影114具备车辆数据储存部114a和设备数据储存部114b。

车辆数据储存部114a储存“object-id”、“Shadow_version”以及“mobility-data”，作为与搭载边缘装置2的车辆有关的数据。

“object-id”是识别搭载边缘装置2的车辆的字符串，作为分区键发挥作用。

“Shadow_version”是表示阴影114的版本的数值，每次作成阴影114，都设定表示作成的时刻的时间戳。

“mobility-data”是上述的标准化车辆数据。

设备数据储存部114b储存“object-id”、“update_time”、“version”、“power_status”、“power_status_timestamp”、“notify_reason”作为与搭载于边缘装置2的硬件、软件、以及状态有关的数据。

“object-id”与在车辆数据储存部114a说明的相同。

“update_time”是表示更新时刻的数值。

“version”是表示边缘装置2的硬件以及软件的版本的字符串。

“power_status”是表示边缘装置2的系统状态的字符串。具体而言，有能够利用全部功能的“电源接通”状态、停止一部分功能的低消耗电力的“电源断开”状态。

“power_status_timestamp”是表示系统状态的通知时刻的数值。

“notify_reason”是表示通知理由的字符串。

这样，阴影114除了车辆数据组以外还包含边缘装置2的信息。此外，设备数据储存部114b也可以不将边缘装置2的信息包含于阴影114而另外存储于ROM42等。设备数据储存部114b也可以不将边缘装置2的信息按时间戳积蓄过去的数据，而仅将最新的数据存储于ROM42等。

储存于上述设备数据储存部114b的“version”“power_status”“notify_reason”等与上述的标准化车辆数据分开地在产生变化时从边缘装置2通知。

最新索引作成部116从阴影存储部113按车辆获取最新的阴影114，使用获取到的阴影114作成最新索引118。而且，最新索引作成部116将作成的最新索引118存储于最新索引存储部117。在最新索引存储部117中按每个车辆(即，每个object-id)存储一个最新索引118。

如图14所示，最新索引118储存“gateway-id”、“object-id”、“shadow-version”、“vin”、“location-lon”、“location-lat”以及“location-alt”。

“object-id”、“shadow-version”与在阴影114说明的相同。

“gateway-id”是识别移动性GW111的信息。是管理中心3例如按国家分别设置等存在多个的情况下识别它们的信息。

“vin”是搭载边缘装置2的车辆固有的登记编号。

“location-lon”是表示搭载边缘装置2的车辆所存在的纬度的信息。

“location-lat”是表示搭载边缘装置2的车辆所存在的经度的信息。

“location-alt”是表示搭载边缘装置2的车辆所存在的高度的信息。

如图12所示，数据管理部121具备索引作成部124和索引存储部125，作为实现将从阴影管理部112获取的最新索引118积蓄为索引126的功能的构成。

索引作成部124根据预先设定的获取时间表从最新索引存储部117获取最新索引118，使用获取到的最新索引118作成数字双123用的索引126。而且，索引作成部124将作成的索引126依次存储到索引存储部125。在索引存储部125中，按车辆存储以时间序列作成的多个索引126。换句话说，存储于索引存储部125的索引126分别表示在作为虚拟的时间空间的数字双123上存在的车辆。

如图15所示，索引126储存“timestamp”、“schedule-type”、“gateway-id”、“object-id”、“shadow-version”、“vin”、“location”以及“alt”。

“timestamp”是以毫秒单位表示索引126被作成的时刻的时间戳。

“schedule-type”表示数据作成源的调度器是定期还是事件。在是定期的情况下“schedule-type”被设定为“Repeat”，在是事件的情况下“schedule-type”被设定为“Event”。

“gateway-id”、“object-id”“shadow-version”、“vin”是从最新索引118继承的信息。

“location”是从最新索引118的“location-lon”、“location-lat”继承的信息，“alt”是从最新索引118的“location-alt”继承的信息。

这里，阴影管理部112也可以构成为省略了最新索引作成部116以及最新索引存储部117。该情况下，索引作成部124也可以获取存储于阴影存储部113的阴影114生成索引126。优选，索引作成部124使用从最新索引存储部117获取到的最新索引118生成索引126。这是使移动性GW111和数据管理部121成为松散耦合的构成之一。

并且，数据管理部121也可以构成为省略索引作成部124以及索引存储部125。该情况下，例如，索引获取部127也可以使用经由API提供部122指定的object-id和时间戳(即，shadow-version)请求由数据获取部119指定的车辆数据的获取。

[3-2-2.服务提供功能]

如图5以及图12所示，服务侧单元120具备API提供部122。API提供部122是为了使服务提供服务器4等外部的服务提供者利用管理中心3具有的功能而准备的接口。以下，将利用API提供部122等的移动性IoT系统1的用户称为服务用户。服务用户是例如进行向车辆后备箱的送货的服务企业。

如图12所示，API提供部122具备认证信息存储部141、授权信息存储部142、车辆识别信息存储部143、以及认证处理部144。另外，作为提供给服务用户的API的种类，具备登录API145、数据获取API146、以及车辆控制API148。

登录API145是为了进行服务用户的认证而提供的API。数据获取API146是为了服务用户获取数据而提供的API。车辆控制API148是为了服务用户进行针对车辆的控制而提供的API。

认证信息存储部141与“服务用户ID”建立对应关系地存储“认证信息”。“服务用户ID”是唯一地识别服务用户的识别信息。“认证信息”是用于认证是服务用户本人的信息，例如，是预先设定的密码。

授权信息存储部142具备授权对象数据库(以下，授权对象DB)和授权级别DB。

如图16所示，授权对象DB与“服务用户ID”建立对应关系地存储“授权级别”“授权对象”“有效期限”。“授权级别”是表示对于服务用户授权的权限的范围的信息。“授权对象”是允许服务用户的访问的车辆的“object-id”的列表。“有效期限”是登记内容有效的期间的开始年月日以及结束年月日。换句话说，授权对象DB是表示针对移动性IoT系统1的各服务用户的权限的登记内容的数据库。若“授权对象”不同，或者，“有效期限”不重复，则也可以对于1个服务用户登记多个授权对象DB。

如图17所示，授权级别DB与“授权级别”建立对应关系地存储“API信息”“获取权限”“有效期限”。授权级别DB是表示“授权级别”的具体内容的数据库。

“授权级别”是识别表示给予授权的数据范围的多个类的信息，例如，也可以按授权级别从低到高的顺序存在“open”“Class0”“clas1”“class2”“class3”“Full”这6级。“授权级别”不限定于能够对于数据进行读出、写入的数据范围的分级，也可以是能够控制动作的动作控制范围的分级等。

“API信息”是向对应的“授权级别”的服务用户提供的API的url。url是UniformResource Locator(统一资源定位器)的缩写。

“获取权限”是对于对应的“授权级别”的服务用户允许的能够获取的数据的列表。授权级别为“open”的情况下，“获取权限”所包含的数据限于谁都能自由访问的信息，例如，也可以包含车辆的位置信息、高度信息。在授权级别为“Full”的情况下，“获取权限”所包含的数据包含有管理中心3管理的全部信息、以及能够从搭载边缘装置2的车辆获取的全部信息。在授权级别为“Class0”～“Class3”的情况下，既可以设定为随着级别上升为0～3，能够访问的数据的数量增加，也可以针对每个级别，设定为能够访问的数据的种类不同。

这里，作为获取权限列举了能够获取的数据，但也可以代替能够获取的数据，或者，除了能够获取的数据以外，还列举有能够利用的功能，例如，针对搭载了边缘装置2的车辆的控制的种类等。作为能够获取的数据，例如从图7所示的数据项目中列举。

若“有效期限”不重复，则1个“授权级别”也可以存在多个设定。

车辆识别信息存储部143存储将对搭载有边缘装置2的车辆唯一分配的“object-id”和该车辆的“vin”建立对应关系的表格信息。

认证处理部144在经由登录API145进行了认证请求的情况下，执行认证处理，经由数据获取API146以及车辆控制API148进行访问请求的情况下，执行授权处理。将在后面描述认证处理以及授权处理。

使用图18对经由API提供部122的访问请求所涉及的步骤进行说明。

登录API145在服务用户登录到移动性IoT系统1时使用。

如箭头L21所示，若登录API145受理来自服务用户的认证请求，则认证处理部144执行认证处理。在认证处理中，将通过登录API145输入的“服务用户ID”“认证信息”与认证信息存储部141的登记内容进行对照。在对照结果为信息一致的情况，即，认证成功的情况下，如箭头L22所示，返回令牌作为认证结果，该令牌是成为允许向移动性IoT系统1的访问的证书的数据。

如图11中的L1所示，数据获取API146是向积蓄于管理中心3的车辆数据(即，索引126以及阴影114)的访问所使用的API。如图11中的L2所示，车辆控制API148是向搭载有边缘装置2的车辆的访问所使用的API。

以下，将数据获取API146、以及车辆控制API148统称为访问API。如图18中的箭头L23所示，访问API若受理来自服务用户的访问请求，则认证处理部144执行授权处理。

若执行授权处理，则认证处理部144根据附加于访问请求的“令牌”确定出“服务用户ID”。接下来，认证处理部144通过检索授权信息存储部142的授权对象DB，确定出被确定的“服务用户ID”的“授权级别”“授权对象”。并且，认证处理部144判定访问请求所示的访问对象的车辆是否在“授权对象”中表示，即，是否允许向服务用户指定的车辆的访问。另外，认证处理部144参照授权级别DB判定访问请求所使用的访问API是否包含于被指定的“授权级别”的“API信息”，即，是否允许利用服务用户指定的API。另外，认证处理部144参照授权级别DB判定访问请求所表示的指示内容是否在被确定的“授权级别”的“获取权限”的范围内，即，是否允许对于服务用户请求的指示内容的访问。而且，在访问对象的车辆未在“授权对象”中表示的情况、访问API未包含于“API信息”的情况、或者指示内容在“获取权限”的范围外的情况下，认证处理部144判定为不授权。在判定为不授权的情况下，认证处理部144如箭头L24所示那样，经由访问API向服务用户通知拒绝访问。在访问对象的车辆被表示在“授权对象”中，并且，访问API包含于“API信息”，并且，指示内容在“获取权限”的范围内的情况下，认证处理部144判定为授权。在判定为授权的情况下，认证处理部144如箭头L25所示，将访问请求转送给作为访问对象的阴影114或者实际车辆。其后，如箭头L26所示，从访问对象返送的访问结果经由访问API提供给服务用户。

此外，在访问API中，也可以使用“object-id”以及“vin”的任一个作为确定车辆的信息，在使用“vin”的情况下，也可以参照车辆识别信息存储部143，将“vin”转换为“object-id”。

图12所示，管理中心3具备索引获取部127、数据获取部119、以及车辆控制部130，作为用于实现经过访问API的访问请求的构成。索引获取部127实现从积蓄于索引存储部125的索引126获取数据的功能。数据获取部119实现从积蓄于阴影存储部113的阴影114获取数据的功能。车辆控制部130利用与边缘装置2的通信功能，实现访问搭载边缘装置2的车辆的功能。

换句话说，经由数据获取API146输入的访问请求(以下，数据获取请求)由索引获取部127处理。另外，经由车辆控制API148输入的访问请求(以下，车辆控制请求)由车辆控制部130处理。

[3-3.数据获取处理]

对数据获取API146受理了数据获取请求的情况下执行的一系列的处理亦即数据获取处理进行说明。具体而言，是在图18中进行认证处理以及授权处理之后，从访问API向访问对象发送了访问请求时的数据获取处理。数据获取处理是使用数据获取API146从在管理中心3内管理的阴影114获取指定的数据的处理。

首先，对数据获取请求所包含的指定信息进行说明。指定信息由服务用户设定。

如图19所示，指定信息包含车辆指定信息、时间指定信息、以及数据指定信息。

车辆指定信息是用于指定成为数据获取的对象的车辆(以下，对象车辆)的信息。车辆指定信息有以列表形成列举对象车辆的车辆ID(即，object-id或者vin)的方法、和指定对象车辆所在的地理区域(以下，区域指定)的方法。除此以外，也可以通过车种、型号等指定对象车辆。

如图20所示，进行区域指定的方法存在矩形指定、以及多边形指定、附近指定这3种。矩形指定是通过左上角坐标、右下角坐标指定矩形的地理区域的方法。坐标使用纬度、经度表示。多边形指定是通过多边形具有的n个顶点的各坐标指定多边形的地理区域的方法。附近指定是通过中心坐标和距中心坐标的距离指定圆形的地理区域的方法。

返回图19，时间指定信息是指定数据被生成的定时的信息。时间指定信息由成为起点的时刻、以及范围表示。范围例如是将最新索引118的生成周期作为单位时间，由1以上的整数表示时间宽度的值。

数据指定信息是指定获取的数据的信息。数据指定信息既可以由列表形式表示标准化车辆数据所示的数据的项名，也可以通过指定标准化车辆数据所示的类别名来表示。在指定了类别名的情况下，指定属于该类别的全部项。另外，在项名以及类别名均未指定的情况下，指定所有项。另外，能够由项名指定的数据也可以包含标准化车辆数据中未包含的行数据。例如，数据指定信息也可以包含与行数据建立对应关系的CAN帧的CANID。

此外，这里示出的车辆指定信息、时间指定信息、数据指定信息的设定方式是一个例子，不局限于上述方法。

接下来，在数据获取API146受理了数据获取请求的情况下，使用图21的流程图对索引获取部127执行的阴影列表生成处理进行说明。

在S110中，索引获取部127参照数据获取请求所示的车辆指定信息，若指定信息是车辆ID列表，则使处理移至S120，若指定信息是区域指定，则使处理移至S130。

在S120中，索引获取部127参照索引存储部125，提取具有车辆ID列表所示的“object-id”并且具有时间指定信息所示的时间范围内的“timestamp”的全部索引126，使处理前进到S150。

在S130中，索引获取部127根据指定信息所示的区域指定设定搜索对象车辆的搜索区域。

在接下来的S140中，索引获取部127参照索引存储部125，提取具有在S130设定的搜索区域内的“location”并且具有时间指定信息所示的时间范围内的“timestamp”的全部索引126，使处理前进到S150。

在S150中，索引获取部127对于在S120或者S140提取出的索引126分别生成组合了索引126所示的“object-id”和“shadow-version”的阴影特定信息。被生成的阴影特定信息成为列举了阴影特定信息的阴影特定信息列表(以下，阴影列表)的构成要素。

在接下来的S160中，索引获取部127将对通过S150生成的阴影列表附加了数据获取请求所示的数据指定信息的阴影访问请求输出至阴影管理部112的数据获取部119，结束处理。

如图22所示，索引获取部127若如箭头L31所示，从数据获取API146接受数据获取请求，则生成阴影列表。阴影列表将数据获取请求所示的车辆指定信息以及时间指定信息作为获取条件，根据该获取条件生成。另外，索引获取部127如箭头L32所示，将组合了生成的阴影列表和数据指定信息的阴影访问请求输出至数据获取部119。

数据获取部119若输入有来自索引获取部127的阴影访问请求，则参照阴影存储部113，提取阴影访问请求的阴影列表所示的各阴影特定信息所对应的阴影114。并且，数据获取部119从提取出的阴影114分别提取指定数据，该指定数据是阴影访问请求的数据指定信息所示的数据。数据获取部119如箭头L33所示，将提取出的指定数据作为访问结果，并返送给成为请求源的数据获取API146。

[3-4.车辆控制处理]

对车辆控制API148受理了来自服务用户的车辆控制请求的情况下执行的一系列的处理亦即车辆控制处理进行说明。车辆控制处理是指定车辆，对于该指定的车辆(以下，对象车辆)请求控制的处理。请求控制的处理例如既可以是请求车载设备的动作的处理，也可以是请求边缘装置2或者ECU210、220、230存储的数据的获取的处理。

首先，对车辆控制请求所包含的指定信息进行说明。

如图23所示，服务用户指定的指定信息包含车辆指定信息、执行对象信息、控制指定信息、优先级信息、限制时间信息、以及车辆认证信息。

车辆指定信息示出一个车辆ID。根据车辆ID确定出的车辆是对象车辆。车辆ID相当于上述的vin或者object-id。

执行对象信息是指定使安装于对象车辆的哪个应用程序执行控制指定信息所示的控制内容的信息，示出识别应用程序的应用ID。

控制指定信息表示使对象车辆执行的具体的控制的内容。例如，也可以包含各座位的门以及行李箱门等各种门的钥匙操作、喇叭以及蜂鸣器等声学设备的操作、头灯以及危险灯等各种灯的操作、照相机以及雷达等各种传感器的操作。控制指定信息也可以包含表示使哪个设备进行哪种动作的信息。控制指定信息也可以示出一个控制，也可以由列表形式表示连续执行的多个控制。此外，列表形式所示的控制需要按列表顺序执行。另外，作为控制指定信息，也可以包含边缘装置2或者ECU210、220、230存储的数据的获取操作。

优先级信息表示朝向对象车辆发送基于车辆控制请求生成的控制指示时的优先级。这里，设定为2等级：高优先级和低优先级。优先级信息既可以由成为请求源的服务用户设定，也可以根据控制指定信息所示的控制的内容自动地设定。另外，车辆控制API148也可以基于规定的规则设定优先级。

限制时间信息表示允许对象车辆的控制的最终时刻。限制时间信息例如将输入了车辆控制请求的时刻+10分钟设定为限度。限制时间信息既可以与优先级信息相同地，由成为请求源的服务用户设定，也可以根据车辆所请求的控制的内容自动地设定。另外，车辆控制API148也可以基于规定的规则设定控制时间信息。

车辆认证信息是判定对象车辆是否可以接受控制指示所使用的信息，由识别对象车辆的所有者的所有者ID和密码构成。车辆认证信息保持于车辆，并且也保持于许可向该车辆的访问的服务用户。此外，共享汽车的情况下，也可以由识别对象车辆的利用者的利用者ID和密码构成车辆认证信息。

如图24所示，车辆控制部130如箭头L41所示，从车辆控制API148输入车辆控制请求，则如箭头L42所示，朝向对象车辆发送基于车辆控制请求生成的1个或者多个控制指示。在图24中，为了简化示出发送一个控制指示的情况。车辆控制部130对于控制指示执行中继控制。中继控制例如包含使通过对对象车辆的访问实现的车辆控制的可靠性提高的控制。

搭载于车辆的边缘装置2若从管理中心3接收控制指示，则对控制指示所示的车辆认证信息和本车辆具有的车辆认证信息进行对照来进行认证。

在认证失败的情况下，边缘装置2将包含表示其主旨的通知的响应发送至管理中心3。

在认证成功的情况下，边缘装置2使根据实施对象信息确定的应用程序执行控制指定信息所示的控制。应用程序根据控制指定信息对于ECU210请求执行控制。ECU210向成为控制的对象的ECU220、230请求执行控制。另外，边缘装置2如箭头L43所示，将包含控制的实施结果的响应发送至管理中心3。

接收到响应的车辆控制部130如箭头L44所示将响应内容返送至车辆控制API148。

[3-5，通信控制]

对车辆控制部130在与车辆的通信时执行的通信控制进行说明。

如图25所示，车辆控制部130具备受理部131、发送管理部132、接收管理部133、以及控制历史存储部134。

控制历史存储部134存储发送至车辆的控制指示的历史数据。历史数据中除了车辆控制请求所示的指定信息的一部分之外还包含次序ID和控制状态。

如图26所示，作为历史数据存储的指定信息包含有车辆指定信息、优先级信息、以及控制指定信息。次序ID是对登记于控制历史存储部134的历史数据(即，控制指示)串行地赋予的编号。控制状态列举了对控制指示预先定义的状态，与该状态建立对应关系地存储有表示变化为该状态的时刻的时间戳。此外，状态有受理了控制指示的发送请求的状态、发送了控制指示的状态、接收了响应的状态等。

受理部131、发送管理部132、接收管理部133参照存储于控制历史存储部134以及阴影存储部113的对象车辆的阴影114执行处理。

[3-5-1.受理处理]

使用图27的流程图，对车辆控制API148受理了车辆控制请求的情况下受理部131执行的受理处理进行说明。

在S210中，受理部131首先执行顺序处理。

这里，使用图28的流程图对顺序处理进行说明。

在S310中，受理部131参照车辆控制请求的指定信息，判定控制指示信息是否以列表形式记载了多个控制，若以列表形式记载则使处理移至S320，若记载一个控制则使处理移至S330。

在S320中，受理部131根据车辆控制请求生成多个控制指示，使处理前进到S340。具体而言，在控制指示信息中以列表形式示出的控制的数目为N个的情况下，根据一个车辆控制请求生成N个控制指示。被生成的N个控制指示的控制指示信息以外的部分使用来自原来的车辆控制请求的复制，控制指示信息示出一个控制。

在S330中，受理部131根据车辆控制请求生成一个控制指示，使处理前进到S340。具体而言，控制指示为直接继承了车辆控制请求的指定信息的内容。

在S340中，受理部131对控制指示赋予次序ID，结束处理。基本而言，按受理了控制指示的顺序将序列号作为次序ID来赋予。在S320中根据一个车辆控制请求生成多个控制指示的情况下，对这些多个控制指示，按原来的车辆控制请求的控制指示信息所示的控制的顺序赋予次序ID。

这里，在控制指示信息中，将以列表形式指定的独立的控制作为单位控制。单位控制不仅是“灯点亮”、“灯熄灭”等单纯的内容，也可以是“反复2次以100msec间隔开关喇叭”、“反复3次以200msec间隔开关头灯”等内容。即，也可以将也包含间隔信息指定同一种类的控制的反复的内容作为单位控制。这样的控制的指示相当于特定控制指示。到各个控制指示到达边缘装置2为止的延迟根据其实时状况各种不同，所以在管理中心3侧管理控制的间隔很困难。但是，在将包含间隔信息的同一控制的反复作为单位控制的情况下，控制的间隔在车辆侧被控制，所以能够使服务用户希望的控制在车辆侧忠实地再现。即，边缘装置2例如对于ECU210发送打开喇叭的指示，待机100msec，发送关闭喇叭的指示，待机100msec，发送打开喇叭的指示，待机100msec，发送关闭喇叭的指示。

返回图27，若顺序处理结束，则在接下来的S220中，受理部131执行唤醒处理。

这里，使用图29的流程图对唤醒处理进行说明。

在S410中，受理部131从阴影存储部113获取对象车辆的最新的阴影114所示的“power_status”。通过该“power_status”可知边缘装置2的电源状态。

在接下来的S420中，受理部131判定“power_status”是否是电源接通，若电源接通则结束处理，若不是电源接通而是电源断开，则使处理移至S430。

在S430中，受理部131对于对象车辆的边缘装置2发送唤醒指示。边缘装置2通过接收唤醒指示，来从电源断开或者睡眠的状态转移到电源接通或者唤醒的状态。

在接下来的S440中，受理部131待机恒定时间(例如1秒)，使处理返回S410。

换句话说，在“power_status”是电源断开的情况下，通过发送唤醒指示，而转移到能够利用边缘装置2的全部功能的唤醒状态。该状态变化通过来自车辆的针对唤醒指示的响应、或者从车辆的周期性的车辆数据的发送，通知给管理中心3，从而对象车辆的阴影114的“power_status”被更新为电源接通。

此外，车辆控制部130也可以构成为参照阴影114的最新的“mobility_data”(即，标准化车辆数据)，进行针对边缘装置2以外的电源控制指示。例如，在对象车辆的点火电源断开的情况下，经由边缘装置2向控制电源的电子控制装置发送点火电源接通指示。另外，在搭载于对象车辆，拍摄车外或者车内的照相机的电源断开的情况下，经由边缘装置2发送照相机启动指示。这样，通过向对象车辆发送预先的指示，能够使边缘装置2可靠地执行受理部131受理的车辆控制请求。

返回图27，若唤醒控制结束，则在接下来的S230中，受理部131将控制指示作为历史数据登记至控制历史存储部134。登记时的控制状态被设定为表示已受理控制的“Accept”。

在接下来的S240中，受理部131执行优先处理结束处理。

这里，使用图30的流程图对优先处理进行说明。

在S510中，受理部131获取成为处理的对象的控制指示的优先级信息。如图23所示，优先级信息被设定为车辆控制请求的指定信息，如图26所示，与控制指示相关联地登记至控制历史存储部134。

在接下来的S520中，受理部131判定获取的优先级信息是否有优先级的设定，若有优先级的设定则使处理移至S540，若没有优先级的设定则使处理移至S530。

在S530中，受理部131将优先级信息设定为低优先级，使处理移至S540。例如，在优先级有3等级以上的情况下，设定最低的优先级的值。

在S540中，受理部131判定优先级信息的设定是否是高优先级，若是高优先级则使处理移至S550，若不是高优先级而是低优先级则使处理移至S560。例如，既可以在进行了优先级的设定的情况下判定为是高优先级，也可以在优先级的值为规定阈值以上的情况下判定为是高优先级。

在S550中，受理部131将控制指示登记至优先队列，使处理前进到S570。队列是具有能够将数据按写入的顺序取出的数据结构的缓冲区。

在S560中，受理部131将控制指示登记至非优先队列，使处理前进到S570。

在S570中，受理部131使优先队列优先，从优先队列以及非优先队列依次取出控制指示，将取出的控制指示传递到发送管理部132，结束处理。也可以使优先队列优先是指例如只要优先队列中残留数据就从优先队列取出数据，仅在优先队列没有数据的情况下，从非优先队列取出数据。另外，也可以以优先队列比非优先队列高的比率取出数据。

[3-5-2.发送侧处理]

使用图31所示的流程图对发送管理部132执行的发送侧处理进行说明。发送侧处理是在S570中从优先队列或者非优先队列取出控制指示，向边缘装置2发送时的处理。

在S610中，发送管理部132获取从受理部131提供的控制指示的指示信息所包含的限制时间信息(即，图23所示的限制时间信息)。

在接下来的S620中，发送管理部132判定当前时刻是否超过了限制时间信息所示的限制时刻，若超过限制时刻则使处理移至S630，若未超过限制时刻则使处理移至S640。例如，考虑到由于到从非优先队列取出为止需要时间而当前时刻超过限制时刻的情况。此外，是否超过的判定也可以使用比限制时刻早控制指示从管理中心3到达车辆所需要的时间的时刻。并且，也可以使用比限制时刻早在车辆中控制指示执行完成所需要的时间的时刻。即，也可以在控制指示到达车辆，到被执行完成为止所需要的时间超过限制时间信息的情况下，移至S630。

这里，也可以代替S620的限制时间信息的判定，将车辆状态的变化作为条件，判定是否控制失败。例如，在作为限制信息，指定了“车辆停止中”这样的条件的情况下，参照最新的阴影114或者属于标准化车辆数据的数据中最新时间戳的数据，判定车辆是否依然停止中。而且，也可以在判定为停止中的情况下，使处理移至S640，在判定为不是停止中的情况下，使处理移至S630。

在S630中，发送管理部132向请求源的车辆控制API148发送通知控制失败的完成通知，并且将控制历史存储部134的控制状态更新为控制失败，结束处理。

在S640中，发送管理部132在向边缘装置2发送控制指示之后，从对象车辆的阴影114获取与从受理部131提供的控制指示建立对应关系的对应数据。也可以在向边缘装置2发送控制指示之后，在待机规定时间之后，从对象车辆的最新的阴影114获取对应数据。对应数据是属于标准化车辆数据的数据中最新时间戳的数据，是具有与在执行控制指示的前后变化的车辆的状态对应的值的数据。例如，在控制指示是门的解锁的情况下，表示成为解锁的对象的门的钥匙的状态的车辆数据成为对应数据。例如，在控制指示是头灯的点亮的情况下，表示成为点亮的对象的头灯的状态的车辆数据成为对应数据。对应数据是表示成为控制对象的设备或者ECU210、220、230的状态的车辆数据。

在接下来的S650中，发送管理部132判定对应数据是否为控制执行后的值，若成为控制执行后的值，则使处理移至S660，若未成为控制执行后的值，则使处理移至S670。此外，在不存在对应数据的控制指示的情况下，也可以省略S640～S660的处理。

在S660中，发送管理部132向请求源的车辆控制API148发送通知控制成功的完成通知，并且将控制历史存储部134的控制状态更新为控制成功，结束处理。

在S670中，发送管理部132执行控制指示的发送。换句话说，将表示控制指示的MQTT消息发布到MQTT代理。与此对应地，发送管理部132将控制历史存储部134的控制状态预先更新为发送完毕。

在接下来的S680中，发送管理部132确认控制历史存储部134的控制状态。换句话说，确认在控制状态中写入最新的时间戳的状态是哪种状态。

在接下来的S690中，发送管理部132判定控制状态是否是表示控制指示已正常到达对象车辆的“Complete”，若是“Complete”则使处理移至S700，若不是“Complete”则使处理移至S710。

在S700中，发送管理部132向成为请求源的车辆控制API148发送通知控制成功的完成通知，并且将控制历史存储部134的控制状态更新为控制成功，结束处理。

在S710中，发送管理部132判定从发送控制指示起的经过时间是否超时，若未超时则使处理移至S720，若超时则使处理移至S730。此外，是否超时的判定通过是否超过预先设定的允许时间(例如10分钟)进行。此外，允许时间也可以基于车辆控制请求时指定的限制时间信息设定。

在S720中，发送管理部132在待机了预先设定的恒定时间(例如1分钟)之后，使处理返回到S680。

在S730中，发送管理部132将超时通知返送给成为请求源的车辆控制API148，并且将控制历史存储部134的控制状态更新为由超时引起的异常结束。并且，发送管理部132使与控制指示对应的MQTT消息无效化，结束处理。即，发送管理部132进行无效化处理，以便向车辆通知可以不在车辆进行已经向车辆发送的控制指示的执行的主旨。

此外，也可以省略无效化处理，对接受了超时通知的服务用户委托是否执行相当于无效化处理的控制的判定。换句话说，例如，在虽然从车辆控制API148输入了使灯点亮的车辆控制请求，但返回了超时通知时，服务用户既可以保持原样放置，也可以为了慎重起见从车辆控制API148输入使灯熄灭的车辆控制请求。

[3-5-3.接收侧处理]

使用图32所示的流程图对接收管理部133执行的接收侧处理进行说明。本处理被反复执行。

在S810中，接收管理部133对于在之前的S430发送的唤醒指示，判定是否接收到唤醒完成通知，若接收则使处理移至S820，若未接收则使处理移至S830。

在S820中，接收管理部133将对象车辆的阴影114的“power_status”更新为电源接通，结束处理。接受该更新，在之前的S420中的判定被肯定判定。

在S830中，接收管理部133对于在之前的S670发送的控制指示，判定是否接收到到达通知，若接收到达通知则使处理移至S840，若未接收到达通知，则结束处理。

在S840中，接收管理部133将成为到达通知的对象的控制指示的存储于控制历史存储部134的历史数据的控制状态从“Accept”更新为“Complete”，完成处理。接受该更新，之前的S690中的判定被肯定判定。

此外，如图25所示，边缘装置2具备唤醒控制部201和指示执行部202。

唤醒控制部201管理搭载有边缘装置2的车辆的电源状态。车辆的电源状态有一部分功能停止的低消耗电力的睡眠状态和全部功能启动的唤醒状态。唤醒控制部201在本车辆处于睡眠状态时，从管理中心3接收发往本车辆的唤醒指示，则使边缘装置2的电源状态转移到唤醒状态，将唤醒完成通知发送至管理中心3。

指示执行部202在本车辆的电源状态为唤醒状态的情况下进行动作。指示执行部202通过对控制指示中附加的车辆认证信息与本车辆具有的车辆认证信息进行对照来进行认证，在认证成功的情况下，由自身执行或者使对应的电子控制装置执行控制指示所示的控制。指示执行部202在认证失败的情况下，将表示其主旨的响应发送至管理中心3，在执行了控制的情况下，将控制结果发送至管理中心3。

[3-6.动作例]

对车辆控制部130的动作例进行说明。

首先，使用图33对对象车辆的边缘装置2的电源状态处于唤醒状态的情况下的典型的动作进行说明。此外，对象车辆的阴影114的“pwer_status”反映了对象车辆的边缘装置2的电源状态，成为“电源接通”。

受理部131如箭头L51所示，将控制指示的历史数据登记至控制历史存储部134。通过历史数据的登记，历史数据的控制状态被设定为“Accept”。另外，受理部131如箭头L52所示，将控制指示发送至发送管理部132。

接受了控制指示的发送管理部132如箭头L53所示，确认对象车辆的阴影114的“power_status”。“pwer_status”是“电源接通”，所以发送管理部132如箭头L54所示，将控制指示发送至对象车辆。以后，发送管理部132如箭头L55所示，周期性地确认历史数据的控制状态。

接受了控制指示的对象车辆如箭头L56所示，将表示已正常接收控制指示的到达通知返送给管理中心3。

接收到到达通知的接收管理部133如箭头L57所示，将历史数据的控制状态从“Accept”更新为“Complete”。

发送管理部132若通过历史数据的周期性的确认，确认控制状态变化为“Complete”，则如箭头L58所示，将表示控制指示正常完成的完成通知发送至请求源的车辆控制API148。

接下来，使用图34对虽然向对象车辆发送了控制指示但未从对象车辆返回到达通知的情况下的动作进行说明。

此外，如箭头L51～L55所示，从受理部131进行历史数据的登记到发送管理部132向对象车辆发送控制指示，开始历史数据的周期性的监视为止与图33所示的内容相同。

发送管理部132在对对象车辆发送控制指示之后，即使经过限制时间信息所示的限制时刻、或者预先设定的允许时间，历史数据的控制状态也保持“Accept”的情况下，如箭头L59所示，对请求源的车辆控制API148发送表示异常结束的超时通知。

接下来，使用图35对对象车辆的边缘装置2的电源状态为睡眠状态的情况下的动作进行说明。此外，对象车辆的阴影114的“pwer_status”反映了对象车辆的边缘装置2的电源状态，成为“电源断开”。另外，如箭头L51～L53所示，从受理部131进行历史数据的登记到发送管理部132确认对象车辆的阴影114的“power_status”为止与图33所示的内容相同。

由发送管理部132确认的对象车辆的阴影114的“pwer_status”是“电源断开”，所以发送管理部132如箭头L60所示那样对于对象车辆发送唤醒指示。以后，发送管理部132周期性地确认对象车辆的“power_status”。

接收到唤醒指示的对象车辆使边缘装置2的电源状态从睡眠状态转移到唤醒状态，如箭头L61所示，将唤醒完成通知返送给管理中心3。

接收到唤醒完成通知的接收管理部133如箭头L62所示，将对象车辆的阴影114的“power_status”更新为“电源接通”。

发送管理部132若如箭头L63所示，通过周期性的确认，确认对象车辆的边缘装置2的“power_status”变化为“电源接通”，则如箭头L64所示，对于对象车辆发送控制指示。

以后的动作与图33以及图34中箭头L55～L59所示的内容相同。

[4.术语的对应]

在以上说明的实施方式中，移动性IoT系统1相当于移动性服务提供系统，管理中心3相当于移动性服务基础服务器，边缘装置2相当于车载机。阴影管理部112相当于第一数据库，数据管理部121相当于第二数据库。API提供部122相当于接口部。S230的处理相当于历史登记部，S310～S340的处理相当于顺序控制部，S510～S570的处理相当于优先处理部。S610～S620的处理相当于发送前判定部。S680～S700、S720的处理相当于送达确认部，S710、S730的处理相当于无效化部，S630、S830～S840的处理相当于历史更新部。控制状态的“Accept”相当于接受状态，“Complete”相当于完成状态，车辆控制请求相当于访问请求。

[5.效果]

根据以上详述的实施方式，起到以下的效果。

(5a)在移动性IoT系统1中，车辆控制请求包含有优先级信息，优先设定为高优先级的控制指示朝向车辆发送根据车辆控制请求生成的控制指示。因此，即使在管理中心3侧滞留许多控制指示这样的状况下，也能够使高优先级的控制指示以较少的延迟完成发送。

(5b)在移动性IoT系统1中，控制指示分别实现独立的一个控制，另外，对各控制指示赋予了使用序列号的次序ID。另外，在接收控制指示的车辆侧，以根据次序ID所示的序列号的顺序执行控制。因此，即使由于管理中心3与车辆(即边缘装置2)之间的通信环境等的影响，到达车辆的控制指示的顺序更换，在车辆侧中，也能够按照车辆控制请求的请求源希望的顺序执行控制。其结果，能够提高基于来自管理中心3的指示的车辆控制的安全性以及可靠性。例如，在需要以严格的顺序性执行的一系列的控制中，通过控制的顺序更换，有可能成为完全不同的控制、或者成为没有意义的控制，但能够抑制这样的状况产生。

(5c)在移动性IoT系统1中，向车辆发送控制指示之后，重复确认控制状态。而且，在变化为表示有来自车辆的响应的状态的情况下，向车辆控制请求的请求源返回完成通知，在即使超过允许时间状态也没有变化的情况下，向车辆控制请求的请求源返回超时通知。因此，根据移动性IoT系统1，能够将控制指示已到达车辆、以及控制指示在允许时间内未到达车辆通知给车辆控制请求的请求源。其结果是，能够在车辆控制请求的请求源中，进行与控制指示的到达的成功与否对应的准确的应对。

(5d)在移动性IoT系统1中，即使控制指示到达车辆也不能在限制时刻之前使控制结束的情况下，不发送控制指示，而将控制失败的主旨通知给车辆控制请求的请求源。另外，在移动性IoT系统1中，在发送控制指示之前，通过参照对象车辆的阴影114，来确认与控制指示建立对应关系的对应数据。而且，在对应数据成为控制执行后的值的情况下，不发送控制指示，而将控制成功的主旨通知给车辆控制请求的请求源。因此，根据移动性IoT系统1，抑制了不必要的控制指示的发送，所以能够减少管理中心3与车辆之间的通信量。

(5e)在移动性IoT系统1中，在发送控制指示之前，通过参照对象车辆的阴影114，来确认对象车辆的“power_status”，在电源断开的情况下，发送唤醒指示。换句话说，在使对象车辆转移到能够执行控制指示的状态之后，发送控制指示。因此，在移动性IoT系统1中，即使是对象车辆的发动机断开的状态，也能够启动对象车辆执行控制。

[6.其他实施方式]

以上，对本公开的一实施方式进行了说明，但本公开不局限于上述实施方式，也能够进行各种变形来实施。

(6a)在本公开中，在控制历史存储部134中以控制指示单位存储了历史数据，但也可以以车辆控制请求单位(即，来自车辆控制API148的请求单位)存储。

(6b)在本公开中，车辆控制部130构成为将来自边缘装置2的针对控制指示的响应按原样以控制指示单位返回给请求源的车辆控制API148。本公开并不局限于此，也可以构成为在根据一个车辆控制请求生成多个控制指示的情况下，将来自边缘装置2的针对控制指示的响应以车辆控制请求单位汇总并返回给请求源的车辆控制API148。

(6c)在本公开中，对于来自管理中心3的控制指示，边缘装置2在控制内容的执行完成的时刻发送向管理中心3的响应，但也可以在受理了控制指示的时刻向管理中心3发送响应。

(6d)本公开所记载的控制部31以及其方法也可以通过构成由被编程为执行通过计算机程序具体化的一个甚至多个功能的处理器以及存储器而提供的专用计算机实现。或者，本公开所记载的控制部31以及其方法也可以由通过由一个以上的专用硬件逻辑电路构成处理器而提供的专用计算机实现。或者，本公开所记载的控制部31以及其方法也可以通过由被编程为执行一个甚至多个功能的处理器以及存储器与由一个以上硬件逻辑电路构成的处理器的组合构成的一个以上的专用计算机实现。另外，计算机程序也可以作为由计算机执行的指令存储于计算机可读取的非过渡性有形记录介质。实现控制部31所包含的各部的功能的方法不一定需要包含软件，也可以使用一个或者多个硬件实现其全部功能。

(6e)也可以通过多个构成要素实现上述实施方式中的一个构成要素所具有的多个功能、或者通过多个构成要素实现一个构成要素所具有的一个功能。另外，也可以通过一个构成要素实现多个构成要素所具有的多个功能、或者通过一个构成要素实现由多个构成要素实现的一个功能。另外，也可以省略上述实施方式的构成的一部分。另外，也可以对于其他的上述实施方式的构成附加或者置换上述实施方式的构成的至少一部分。

(6f)除了上述的管理中心3以外，也能够以将该管理中心3作为构成要素的系统、用于使计算机作为该管理中心3发挥作用的程序、记录了该程序的半导体存储器等非过渡性实体记录介质、车辆访问控制方法等各种形式实现本公开。

Claims (14)

1.一种移动性服务基础服务器，具备：

车辆侧单元(110)，具有存储多个阴影的第一数据库(112)，上述阴影基于从搭载于车辆的车载机提供的车辆数据，按每个上述车辆生成，表示特定的时刻下的上述车辆的状态；以及

服务侧单元(120)，具有第二数据库(121)和接口部(122)，上述第二数据库存储与积蓄于上述第一数据库的上述阴影分别对应，具有检索上述阴影所使用的信息的索引，上述接口部构成为受理来自外部的访问请求，

上述车辆侧单元还具备车辆控制部(130)，上述车辆控制部构成为在上述接口部受理了针对上述车辆的上述访问请求的情况下，通过进行与搭载于对象车辆的上述车载机的无线通信来执行对上述对象车辆的访问，上述对象车辆是成为访问的对象的上述车辆，

上述车辆控制部构成为对于在与上述车载机之间收发的控制指示执行中继。

2.根据权利要求1所述的移动性服务基础服务器，其中，

上述车辆控制部具备：

控制历史存储部(134)，存储对于上述车辆发送的上述控制指示的内容以及控制状态；

历史登记部(S230)，将上述控制状态设定为接受状态并将上述控制指示登记至上述控制历史存储部；

送达确认部(S680～S700，S720)，在发送上述控制指示后，通过监视上述控制状态，来确认上述控制指示的送达；以及

历史更新部(S830～S840)，在接收来自上述车载机的针对上述控制指示的响应时，将上述控制历史存储部中的上述控制指示的上述控制状态更新为完成状态。

3.根据权利要求2所述的移动性服务基础服务器，其中，

上述车辆控制部还具备：

无效化部(S710，S730)，在通过上述送达确认部在预先设定的允许时间内未确认上述控制指示的送达的情况下，使上述控制指示无效化。

4.根据权利要求2或者3所述的移动性服务基础服务器，其中，

上述车辆控制部还具备：

发送前判定部(S610～S620)，在向上述车载机发送上述控制指示之前，在由上述控制指示指定的允许时间内，向上述车载机发送上述控制指示，判定是否能够完成上述车载机中的执行，

在由上述发送前判定部做出否定判定的情况下，上述历史更新部(S630)中止向上述车载机的上述控制指示的发送，将上述控制历史存储部中的上述控制指示的上述控制状态更新为表示发送失败的状态。

5.根据权利要求1～4的任一项所述的移动性服务基础服务器，其中，

上述控制指示具有优先级，

上述车辆控制部具备优先处理部(S510～S570)，该优先处理部根据上述优先级设定上述控制指示的发送顺序。

6.根据权利要求5所述的移动性服务基础服务器，其中，

上述优先级针对每个上述访问请求由上述接口部设定。

7.根据权利要求5所述的移动性服务基础服务器，其中，

上述优先级根据上述访问请求所示的控制内容决定。

8.根据权利要求1～7的任一项所述的移动性服务基础服务器，其中，

上述车辆控制部具备顺序控制部(S310～S340)，该顺序控制部对需要顺序控制的一系列的上述控制指示赋予表示控制的执行顺序的序列号。

9.根据权利要求8所述的移动性服务基础服务器，其中，

上述顺序控制部构成为在上述访问请求包含有需要顺序控制的多个控制的情况下，根据该访问请求生成多个上述控制指示，对于上述控制指示分别赋予上述序列号。

10.一种移动性服务提供系统，其中，具备：

车载机，搭载于车辆；以及

移动性服务基础服务器，向搭载上述车载机的上述车辆提供移动性服务，

上述移动性服务基础服务器具备：

车辆侧单元，具有存储多个阴影的第一数据库，上述阴影基于从上述车载机提供的车辆数据，按每个上述车辆生成多个，表示特定的时刻下的上述车辆的状态；以及

服务侧单元，具有第二数据库和接口部，上述第二数据库存储与积蓄于上述第一数据库的上述阴影分别对应，具有检索上述阴影所使用的信息的索引，上述接口部构成为受理来自外部的访问请求，

上述车辆侧单元还具备车辆控制部，该车辆控制部构成为在上述接口部受理了针对上述车辆的上述访问请求的情况下，通过进行与搭载于对象车辆的上述车载机的无线通来执行对上述对象车辆的访问，上述对象车辆是成为访问的对象的上述车辆，

上述车辆控制部构成为对于在与上述车载机之间收发的控制指示执行中继控制。

11.根据权利要求10所述的移动性服务提供系统，其中，

上述车辆控制部构成为能够发送特定控制指示作为上述控制指示，上述特定控制指示将各指示的控制定时包含在内规定了针对对象设备的一系列指示，上述对象设备是搭载于上述对象车辆的成为控制对象的车载设备，

上述车载机构成为在接收到上述特定控制指示的情况下，将该特定控制指示所示的上述一系列指示所包含的各个指示根据上述控制定时一个一个依次对于上述对象设备输出。

12.根据权利要求10或者11所述的移动性服务提供系统，其中，

上述车辆控制部具备顺序控制部，该顺序控制部构成为对于需要顺序控制的一系列的上述控制指示赋予表示控制的执行顺序的序列号，

上述车载机构成为将从上述移动性服务基础服务器接收的上述控制指示按赋予至该控制指示的上述序列号的顺序执行。

13.一种车辆访问控制方法，其中，

是移动性服务基础服务器中的车辆访问控制方法，移动性服务基础服务器具备：第一数据库，存储多个阴影，上述阴影基于从搭载于车辆的车载机提供的车辆数据，按每个上述车辆生成，表示特定的时刻下的上述车辆的状态；第二数据库，存储与积蓄于上述第一数据库的上述阴影分别对应，具有检索上述阴影所使用的信息的索引；以及接口部，构成为受理来自外部的访问请求，在上述车辆访问控制方法中，

在上述接口部受理了针对上述车辆的上述访问请求的情况下，通过进行与搭载于对象车辆的上述车载机的无线通信来执行对上述对象车辆的访问，上述对象车辆是成为访问的对象的上述车辆，

在对上述对象车辆的访问中，对于在与上述车载机之间收发的控制指示执行中继控制。

14.一种程序，其中，

使与第一数据库、第二数据库、以及接口部一起构成移动性服务基础服务器的计算机作为车辆控制部发挥作用，

上述第一数据库存储多个阴影，上述阴影基于从搭载于车辆的车载机提供的车辆数据，按每个上述车辆生成，表示特定的时刻下的上述车辆的状态，上述第二数据库存储与积蓄于上述第一数据库的上述阴影分别对应，具有检索上述阴影所使用的信息的索引，上述接口部构成为受理来自外部的访问请求，

在上述接口部受理了针对上述车辆的上述访问请求的情况下，上述车辆控制部通过进行与搭载于对象车辆的上述车载机的无线通信来执行对上述对象车辆的访问，对于在对该对象车辆的访问中在与上述车载机之间收发的控制指示，执行中继控制，上述对象车辆是成为访问的对象的上述车辆。