软件查询信息管理系统及软件查询信息管理方法与流程

1.本发明涉及软件查询信息管理系统及软件查询信息管理方法。


背景技术：

2.在专利文献1中，记载了一种车辆设计支援装置，以解决在车辆的设计过程中用于确认设计是否符合法规限制的作业需要很大工作量的课题作为目的而构成。车辆设计支援装置具备：法规限制信息存放机构，按车辆所安装的每个部件存放关于与部件相关的法规限制的信息；输入用于确定车辆的形状的车辆形状信息的机构；输入用于确定车辆所安装的部件的形状及部件的安装位置的部件形状信息的机构；判定部，从法规限制信息存放机构读出与部件相关的部件关联法规限制信息，判定部件是否满足部件关联法规限制信息中包含的限制条件；以及输出部，与判定部的判定结果相应地改变部件的显示形式来显示。
3.在先技术文献
4.专利文献
5.[专利文献1]日本特开2005—173761号公报


技术实现要素：

[0006]
发明所要解决的课题
[0007]
近来，随着无线通信技术的发展，汽车厂商等车辆的提供者能够在车辆制造时或销售后，经由ota(空中下载(over the air))，向车辆所搭载的ecu(电子控制单元(electronic control unit))等设备装入软件或者对软件进行更新(性能变更、功能变更、功能追加等)。由此，车辆的提供者例如能够预料未来追加自动驾驶功能等来进行汽车的开发、生产、销售，可以想到今后车辆所搭载的软件的更新机会剧增。
[0008]
鉴于这种状况，在wp29(世界车辆法规协调论坛)中针对软件的更新正进行国际标准的策划制定。在wp29中例如正在探讨建立如下等制度：对软件的更新给车辆的式样认证造成的影响进行评价并使其结果成为文档；在软件的更新对已经受到的式样认证的内容造成影响的情况下向政府(国土交通省等)进行报告；导入定义如下编号的概念(以下称为“软件查询编号”)，该编号以版本级别对受到式样认可的车载系统中装入的一个以上软件进行区别并进行集约；以及，按照政府的要求，提交与软件的更新相关联的证据等信息。
[0009]
在开始了上述的制度的情况下，车辆的提供者需要针对车辆所搭载的大量设备，高效且切实地基于其中装入的软件赋予软件查询编号，分析对这些软件进行了更新时对式样认可造成的影响，取得关于式样认可需要报告的证据等。
[0010]
但是，车辆所搭载的设备大多通常由供应商等设备的供应者向车辆的提供者(oem)供应，可追踪性信息等与软件相关的信息在供应者侧被管理，预想到在应对上述制度时，会发生用于将车辆的提供者侧管理的式样认可等的信息和与软件相关的信息建立关联的烦杂作业。在上述专利文献1中，虽然判定车辆所安装的部件是否满足部件关联法规限制信息中包含的限制条件，但关于统筹地对设备的供应者侧管理的信息与车辆的提供者侧管
理的信息进行管理的技术，却完全没有公开。
[0011]
本发明鉴于这样的背景而作出，其目的在于，提供能够高效地管理与针对车辆所搭载的设备中装入的软件的法定认可相关的信息的软件查询信息管理系统及软件查询信息管理方法。
[0012]
用于解决课题的手段
[0013]
用于达成上述目的的本发明之一是一种信息处理系统，管理与针对实现车辆所搭载的设备的功能的软件的法定认可相关的信息，与法规id建立关联地存储设备要求规格，该法规id是用于确定对车辆受到法定认可所需的要件进行规定的法规的信息，该设备要求规格是与所述法规对所述设备要求的规格相关的信息，所述信息处理系统取得可追踪性信息，该可追踪性信息是与所述设备要求规格建立了关联的与所述设备的可追踪性相关的信息，所述可追踪性信息包含用于确定所述设备中装入的软件的软件id，所述信息处理系统生成软件查询编号，该软件查询编号是将对应于与取得的所述可追踪性信息建立了关联的所述设备要求规格的所述法规id、与一个以上的所述软件id建立关联的信息。
[0014]
其他的本技术所公开的课题及其解决方法通过具体实施方式部分及附图而明确。
[0015]
发明效果
[0016]
根据本发明，能够高效地管理与针对车辆所搭载的设备中装入的软件的法定认可相关的信息。
附图说明
[0017]
图1是说明与车辆式样的认可相关的信息和软件信息的关联的图。
[0018]
图2是说明软件查询信息的构成例的图。
[0019]
图3是车辆构成信息的例子。
[0020]
图4是设备供应者及车辆提供者所管理的可追踪性信息的例子。
[0021]
图5是表示软件查询信息管理系统的概略性的构成的图。
[0022]
图6是构成设备供应者系统或车辆提供者系统的信息处理装置的例子。
[0023]
图7是说明软件查询编号生成处理的流程图。
[0024]
图8是由车辆提供者管理的可追踪性信息的例子。
[0025]
图9是说明软件更新管理处理的流程图。
[0026]
图10是说明软件查询信息参照处理的流程图。
[0027]
图11是软件查询信息管理画面的例子。
[0028]
图12是关联信息查询画面的例子。
[0029]
图13是软件查询信息新注册画面的例子。
[0030]
图14是软件查询信息更新画面的例子。
[0031]
图15是未能判断软件查询编号是否需要更新的情况下的显示例。
[0032]
附图标记说明：
[0033]
1软件查询信息管理系统，2车辆提供者，3a～3c设备供应者，6软件查询信息，10信息处理装置，21认可软件查询信息，22法规要求信息，23车辆要求规格，30可追踪性信息，31设备要求规格，32设计书，33源码，40车辆可追踪性信息，100车辆提供者系统，111信息管理部，112车辆信息管理部，1121车辆信息，113法规信息管理部，1131法规信息，114信息综合
部，115软件查询编号生成部，116软件查询信息管理部，200设备供应者系统，211可追踪性信息管理部，212可追踪性信息转换发送部，s700软件查询信息生成处理，s900软件更新管理处理
具体实施方式
[0034]
以下，参照附图说明本发明的实施方式。此外，在以下的说明中，有时针对相同或者相似的构成附加共通的标记并省略重复的说明。
[0035]
在以下的说明中，“法规”是指车辆为了受到式样认证等关于是否满足治安标准的认证而需要遵守的法令(法律、政令、规则等)。另外，法规不限于日本的法规，也包含车辆的出口目的地(目的国)中的法规。
[0036]
在以下的说明中，“软件”是指被写入至ecu(电子控制单元(electronic control unit))的控制命令及控制命令的执行所需的数据。
[0037]
在以下的说明中，“将软件装入设备”是指将软件记录(存储、写入、下载等)至设备的存储元件。另外“对信息进行管理”是指将信息存放(存储)于数据库等并以能够进行检索、更新、删除等操作的状态管理。
[0038]
在以下的说明中，有时将“可追踪性(tracability)”简写为“追踪性”。另外在以下的说明中，“证据(evidence)”是指测试结果、评审结果等、车辆的提供者在进行式样认证等时向政府(国土交通省等)提交的关联资料。
[0039]
在以下的说明中，将车辆的提供者(汽车厂商等车辆的制造者等)称为“车辆提供者”。另外，将车辆所搭载的设备(ecu等)或在车辆之外与车辆协作的服务器装置等的供应者(供应商)称为“设备供应者”。但是，车辆提供者及设备供应者均不过是为了方便说明而定义的，以下说明的各种构成的管理主体、运用主体不一定进行限定。
[0040]
在以下的说明中，未特别明示制作主体的信息例如由用户的输入操作或现有的信息处理系统设定。
[0041]
＜软件查询信息＞
[0042]
针对车辆提供者、设备供应者关于车辆所搭载的ecu等设备中装入的软件所管理的信息(以下称为“软件查询信息6”)进行说明。
[0043]
图1是说明软件查询信息6的图。如该图所示，软件查询信息6包含：作为在车辆提供者2侧管理的信息的认可软件查询信息21、法规要求信息22及车辆要求规格23、系统综合验证结果报告书25、合格性验证结果报告书26、设备要求规格31、软件37及可追踪性信息20。另外，软件查询信息6包含作为在设备供应者3a～3c侧管理的信息的设备要求规格31、设计书32及源码33、单元验证结果报告书34、ecu综合验证结果报告书35、ecu合格性验证结果报告书36、软件37及可追踪性信息30。软件查询信息6按车辆的模型等一定的组分别被管理。在本实施方式中，软件查询信息6设为按每个模型被管理。
[0044]
认可软件查询信息21是表示接受认可的法规和与该认可相关联的软件之间的对应的信息。
[0045]
图2是说明认可软件查询信息21的图。认可软件查询信息21包含将如下数据建立对应而成的信息：作为法规的标识符的法规id(d211)；作为在每次软件被更新等关于该法规进行认可时新被赋予的标识符(对各认可进行区别的标识符)的软件查询编号(认可标识
符)d212；作为软件的标识符的软件id(d213)；以及作为用于验证以软件id(d213)表示的二进制数据的完整性的数据的验证数据d214。在此，软件id包含用于确定软件的种类的信息(用于识别ecu的id、模组的名称等)、以及软件的版本信息。此外，也可以设为软件id仅包含版本信息，关于用于确定软件的种类的信息另行管理。像这样，认可软件查询信息21由法规id、软件查询编号及一个以上的软件id(名称 版本信息)的组合构成，因此能够以版本级别对软件进行区别来管理软件查询信息6。
[0046]
在该图中，在d21a的记录的法规id(d211)中，设定了表示协定规则第79号(操舵装置所涉及的车辆的认可所相关的统一规定)第2系列的“r7902”。另外，该记录表示：作为表示构成该法规的功能的软件的组合的软件查询编号d212设定了“r7902001”，构成其的软件id的组合是“ecu a vl.0”，“ecu b vl.0”及“ecu c vl.0”。
[0047]
返回图1，法规要求信息22包含表示在认可时法规所要求的内容的信息。在该图中，作为用于遵照“r7902”的法规要求信息22，例示了有“preq79
‑
1”、“preq79
‑
2”。它们例如对应于“如果在最多15秒经过后驾驶者未保持转向器控制，则施加光学警告”、“如果在最多30秒经过后驾驶者未保持转向器控制，则不仅施加上述的信号而且施加声音警告”等要件。
[0048]
车辆要求规格23包含表示从法规或其他要求导出的车辆系统的要求规格的信息。在该图中，作为车辆要求规格23，例示了有“sreq4”、“sreq5”。它们例如对应于从上述的法规要求导出的“如果在最多15秒经过后驾驶者未保持转向器控制，则施加光学警告”、“如果在最多30秒经过后驾驶者未保持转向器控制，则不仅施加上述的信号而且施加声音警告”等要件。另外，车辆构成信息24包含用于构成车辆系统的体系结构、ecu构成、模型等的信息。
[0049]
图3是车辆构成信息24中包含的信息的一例。例示的车辆构成信息24具有如下构造：以作为按车辆的每个模型被赋予的标识符的模型id作为根，以层级(树形)对作为车辆所搭载的设备的标识符的设备id进行管理。通过例示的车辆构成信息24，能够取得模型id与构成该模型id的模型的设备id之间的对应。此外，设备供应者3a～3c所管理的信息(设备要求规格31、设计书32等)通常也被赋予了模型id、设备id，因此能够取得这些信息与车辆构成信息24之间的对应。
[0050]
返回图1，系统综合验证结果报告书25包含与由车辆要求规格23、车辆构成信息24规定的设计内容的验证相关的各种信息(测试规格书、测试结果报告等)。在该图中，作为系统综合验证结果报告书25，例示了有“trsreq 4”、“trsreq 5”等。
[0051]
合格性验证结果报告书26包含与由法规要求信息22规定的功能的合格性验证相关的各种信息(测试规格书、测试结果报告等)。在该图中，作为合格性验证结果报告书26，例示了有“trpreq 79
‑
1”、“trpreq 79
‑
2”等。
[0052]
设备要求规格31包含表示基于车辆要求规格23和车辆构成信息24针对车辆所搭载的设备的规格所要求的内容的信息。在该图中，作为ecu a的设备要求规格31，例示了有“req a
‑
1”、“req a
‑
2”、“req a
‑
3”等。它们例如对应于从上述的车辆要求规格23“sreq4”导出的“进行检测(15秒)”、“进行检测(30秒)”及“向ecu b通知”。该图除此之外，表示了为了实现车辆要求规格23而存在面向ecu b、ecu c的设备要求规格。设备要求规格31由车辆提供者2规定而向设备供应者公开。对于ecu的整体要件(例如“ecu a要件vl.0”)由这些设备要求规格(“req a
‑
1”、“req a
‑
2”、“req a
‑
3”)的组合构成。从设备供应者3向车辆提供者2
提示的软件与该要求被建立对应地管理，例如，在被提供的软件是1个二进制数据的情况下，其与对于ecu的整体要件建立对应。
[0053]
设计书32包含与设备的设计相关的各种信息(基本设计书、详细设计书、测试规格书、测试结果等)。在该图中，作为ecu的设计书32，例示了管理着由“dsn a
‑
1”、“dsn a
‑
2”、“dsn a
‑
3”等构成的设计内容。
[0054]
源码33是设备中装入的软件的源码。在该图中，作为源码33，例示了管理着由多个函数或者类(“func a
‑
1”、“func a
‑
2”、“func a
‑
3”)等构成的源码“al.c”等。
[0055]
单元验证结果报告书34包含与函数级别的验证相关的各种信息(测试规格书、测试结果报告等)。在该图中，作为单元验证结果报告，例示了有“trfunc a
‑
1”、“trfunc a
‑
2”、“trfunc a
‑
3”等。
[0056]
ecu综合验证结果报告书35包含与由设计书32规定的设计内容的验证相关的各种信息(测试规格书、测试结果报告等)。在该图中，作为ecu综合验证结果报告，例示了有“trdsn a
‑
1”、“trdsn a
‑
2”、“trdsn a
‑
3”等。
[0057]
ecu合格性验证结果报告书36包含与由设备要求规格31规定的功能的合格性验证相关的各种信息(测试规格书、测试结果报告等)。在该图中，作为ecu综合验证结果报告，例示了有“trreq a
‑
1”、“trreq a
‑
2”、“trreq a
‑
3”等。
[0058]
软件37包含基于设备要求规格31被制作的软件。软件由设备供应者3制作，并向车辆提供者2提供。在软件中包含：描述了控制命令的二进制码以及在执行该控制命令中利用的数据(校准数据等)、用于验证它们的完整性的验证数据。软件37通过对设备供应者3的源码33进行编译而被生成。
[0059]
可追踪性信息20是由车辆提供者制作/管理的成果间的关联信息。在可追踪性信息20中，有法规要求信息22与车辆要求规格23的关联、车辆要求规格23与设备要求规格31的关联、法规要求信息22与合格性验证结果报告书26的关联、车辆要求规格23与合格性验证结果报告书26的关联等。
[0060]
可追踪性信息30是将由设备供应者3制作并管理的成果间建立关联的信息。在可追踪性信息30中，有设备要求规格31与设计书32的关联、设计书32与源码33的关联、源码33与单元验证结果报告书34、设计书32与ecu综合验证结果报告书35的关联、设备要求规格31与ecu合格性验证结果报告书36的关联、设备要求规格31与软件37的关联等。
[0061]
在图4中表示可追踪性信息的例子(可追踪性信息20、30)。例如，该图所示的可追踪性信息20表示车辆要求规格23与设备要求规格31的关联，标记20a的记录表示车辆要求规格“sreq4 vl.0”通过设备要求规格“req a
‑
l vl.0”、“req a
‑
2vl.0”、“req b
‑
2vl.0”、“req b
‑
3vl.0”、“req c
‑
l vl.0”、“req c
‑
2vl.0”被满足。另外，该图所示的可追溯性信息30表示设计书32与源码33的关联，标记30a的记录表示设计“dsn a
‑
l vl.0”通过函数“func a
‑
l vl.0”被安装。在可追踪性信息20中，要求规格等被分别赋予id，表示id间的关联。作为这样的可追踪性信息的表现例，有该图所例示的表形式等。
[0062]
图1所示的信息例如以车辆模型单位被管理。在图1中，关于ecu a的设备供应者3的管理信息的例3a进行了说明，但设备要求规格31、设计书32及源码33、单元验证结果报告书34、ecu综合验证结果报告书35、ecu合格性验证结果报告书36及软件37按每个设备供应者3被制作并被管理。例如，ecu b、ecu c的设备供应者3各自管理信息3b、信息3c。
[0063]
＜软件查询信息管理系统＞
[0064]
接下来，关于作为一个实施方式表示的信息处理系统(以下称为“软件查询信息管理系统1”)进行说明。
[0065]
在图5中表示软件查询信息管理系统1的概略性的构成。软件查询信息管理系统1是管理软件查询信息6的系统，包含作为在车辆提供者2侧管理的信息处理系统的车辆提供者系统100、以及作为在各个设备供应者3a～3c侧管理的信息处理系统的一个以上设备供应者系统200。
[0066]
车辆提供者系统100及设备供应者系统200均使用一个以上的信息处理装置构成。设备供应者系统200与车辆提供者系统100经由通信网络(wan(广域网(wide area network))、lan(局域网(local area network))、互联网、专用线、各种公众通信网络等)以能够通信的方式被连接。
[0067]
在图6中表示构成车辆提供者系统100或设备供应者系统200的信息处理装置(计算机)的硬件构成例。如该图所示，例示的信息处理装置10具备处理器11、主存储装置12、辅助存储装置13、输入装置14、输出装置15及通信装置16。它们经由未图示的总线(bus)等通信手段以能够通信的方式被连接。
[0068]
信息处理装置10中例如也可以被导入操作系统、设备驱动器、文件系统、dbms(数据库管理系统(database management system))(关系型数据库、nosql等)等。
[0069]
信息处理装置10例如是桌面型的个人计算机、办公电脑、主机架计算机、移动通信终端(智能电话、平板电脑、可穿戴终端、笔记本型的个人计算机)等。
[0070]
信息处理装置10例如也可以通过使用由云系统提供的云服务器那样虚拟性的信息处理资源而被实现，车辆提供者系统100、设备供应者系统200也可以作为云服务被提供。
[0071]
处理器11例如通过使用cpu(中央处理单元(central processing unit))、mpu(微处理单元(micro processing unit))、gpu(图形处理单元(graphics processing unit))、ai(人工智能(artificial intelligence))芯片、fpga(现场可编程逻辑门阵列(field programmable gate array))、asic(应用型专用集成电路(application specific integrated circuit))等而构成。
[0072]
主存储装置12是存储程序、数据的装置，例如是rom(只读存储器(read only memory))、ram(随机存取存储器(random access memory))、非易失性存储器(nvram(non volatile ram))等。
[0073]
辅助存储装置13例如是ssd(固态驱动器(solid state drive))、硬盘驱动器、光学式存储装置(cd(紧凑盘(compact disc))、dvd(数字通用盘(digital versatile disc))等)、存储系统、ic卡、sd卡、光学式记录介质等记录介质的读取/写入装置、云服务器的存储区域等。能够经由记录介质的读取装置或通信装置16向辅助存储装置13读入程序、数据。辅助存储装置13所存放(存储)的程序、数据被随时读入至主存储装置12。
[0074]
输入装置14是受理从外部的输入的接口，例如是键盘、鼠标、触摸面板、读卡器、声音输入装置等。
[0075]
输出装置15是输出处理经过、处理结果等的各种信息的接口。输出装置15例如是使上述的各种信息可视化的显示装置(液晶监视器、lcd(液晶显示器(liquid crystal display))、图形卡等)、使上述的各种信息成为声音的装置(声音输出装置(扬声器等))、使
上述的各种信息成为字符的装置(打印装置等)。输出装置15与输入装置14一起构成用户界面。
[0076]
此外，例如也可以构成为信息处理装置10经由通信装置16与其他装置(智能电话、平板电脑、笔记本型计算机、各种便携信息终端等)进行信息的输入、输出。
[0077]
通信装置16实现与其他装置之间的通信。通信装置16是经由通信网络5实现与其他装置之间的通信的无线方式或者有线方式的通信接口，例如是nic(网络接口卡(network interface card))、无线通信模组、usb(通用串行总线(universal serial bus))模组、串行通信模组等。
[0078]
返回图5，关于各系统所具备的功能进行说明。车辆提供者系统100具备可追踪性信息管理部110、信息管理部111、法规信息管理部113、可追踪性信息转换部118、信息综合部114、软件查询编号生成部115、软件查询信息管理部116及软件更新管理部117。它们的功能通过由构成车辆提供者系统100的信息处理装置10的处理器11读出并执行主存储装置12中存放的程序来实现，或者通过信息处理装置10的硬件(fpga、asic、ai芯片等)实现。
[0079]
可追踪性信息管理部110接收从设备供应者系统200送来的后述的可追踪性信息30’并进行管理。另外，可追踪性信息管理部110对图1所示的由车辆提供者生成的可追踪性信息20进行管理。
[0080]
信息管理部111对图1所示的车辆要求规格23、车辆构成信息24、设备要求规格31、软件37、系统综合验证结果报告书25(在图5中未图示)及合格性验证结果报告书26(在图5中未图示)进行管理。信息管理部111既可以通过多个工程工具个别地管理，也可以通过一个工程工具综合地管理。总之，只要能够在需要时参照所需的信息即可。
[0081]
返回图5，法规信息管理部113对与车辆的式样认可时被适用的法规相关的信息(以下称为“法规信息1131”)进行管理。法规信息1131包含法规要求信息22、向政府的申报文件的模板、以及申报完成文件等。法规信息管理部113不仅对日本的法规信息，而且对日本以外的车辆的出口目的地(目的国)的法规信息也进行管理。根据由目的国信息确定的出口目的地的法规信息，能够得到在出口目的地取得式样认证所需的信息。
[0082]
可追踪性信息转换部118读出以设备供应者所制作的形式被制作的可追踪性信息30’，并转换为车辆提供者能够利用的共通形式。在此，作为表现可追踪性信息的共通的表现形式，能够适用rdf(资源描述框架(resource description framework))等。
[0083]
信息综合部114基于被转换为共通形式的可追踪性信息30’和可追踪性信息20，将在车辆提供者系统100及设备供应者系统200各自中被管理的信息(信息管理部111及法规信息管理部113各自所管理的信息)建立关联，从而生成车辆可追踪性信息40，车辆可追踪性信息40是将法规id与“将法规要求信息22、车辆要求规格23、设备要求规格31、设计书32、源码33及法规要求信息22建立关联而成的信息”建立关联而成的信息。像这样，通过以rdf形式共通地对可追踪性信息进行管理，能够利用查询语句sparql(协议和rdf查询语言(protocol and rdf query language))等，易于检索相关联的信息。
[0084]
软件查询编号生成部115基于车辆可追踪性信息40，生成认可软件查询信息21。
[0085]
软件查询信息管理部116将信息综合部114所生成的车辆可追踪性信息40与软件查询编号生成部115所生成的认可软件查询信息21(相当于图1的认可软件查询信息21)建立关联并管理。
[0086]
软件更新管理部117进行与车辆所搭载的设备中装入的软件被更新时的认可软件查询信息21等的更新相关的处理。另外，软件更新管理部117受理用于从用户指定软件的键信息(例如，源码中描述的函数或类的标识符(以下称为“函数id”)、法规id等)等，确定包含了包括所受理的键信息在内的源码的软件查询信息6，将与确定的软件查询信息6相关的信息向用户提供。用户通过参照上述信息，例如能够容易而且迅速地得到与需要接受再认可的对象(软件、设备、法规等)或接受认可所需的测试(验证)相关的信息等。
[0087]
接下来，关于图5所示的设备供应者系统200的功能进行说明。如该图所示，设备供应者系统200具备信息管理部210、可追踪性信息管理部211及可追踪性信息转换发送部212。它们的功能通过由构成设备供应者系统200的信息处理装置10的处理器11读出并执行主存储装置12中存放的程序来实现，或者通过信息处理装置10的硬件(fpga、asic、ai芯片等)实现。
[0088]
图5所示的信息管理部210对图1所示的设备要求规格31、设计书32及源码33、单元验证结果报告书34、综合验证结果报告书35、合格性验证结果报告书36、软件37等(仅图示一部分)的成果进行管理。信息管理部111既可以通过多个工程工具个别地管理，也可以通过一个工程工具综合地管理，只要构成为在需要时能够参照所需的信息即可。
[0089]
可追踪性信息管理部211对图1所示的可追踪性信息30进行管理。
[0090]
可追踪性信息转换发送部212将可追踪性信息管理部211所管理的可追踪性信息30向车辆提供者系统100发送。此时，也可以对在设备供应者3侧管理的可追踪性信息(可追踪性信息30)之中的希望在设备供应者3a～3c侧加以保密的信息(例如，源码的希望加以保密的部分(函数名等))进行转换(加密或用别的码置换等)，并作为可追溯性信息30’向车辆提供者系统100发送。通过像这样对信息进行转换，能够在对设备供应者3的信息进行保密的状态下，根据要求生成直到源码的可追踪性信息。在进行转换时，生成可追踪性信息30和可追踪性信息30’的转换表38并保存。在设备供应者3被车辆提供者2要求提供信息的情况下，通过转换表38对数据进行逆转换，并参照所需的数据。
[0091]
＜处理说明＞
[0092]
接下来，关于在软件查询信息管理系统1中进行的处理进行说明。
[0093]
＜软件查询信息的生成处理＞
[0094]
图7是说明在生成软件查询信息6时在车辆提供者系统100中进行的处理(以下称为“软件查询信息生成处理s700”)的流程图。以下，结合该图关于软件查询信息生成处理s700进行说明。此外，设为在软件查询信息生成处理s700开始时，可追踪性信息管理部110管理着可追踪性信息20(车辆提供者所生成的可追踪性信息)及可追踪性信息30’(从设备供应者系统200取得的可追踪性信息30’)。另外，设为在上述开始时，信息管理部111管理着车辆要求规格23、设备要求规格31等的信息。另外，设为在上述开始时，法规信息管理部113管理着预先由用户等设定的法规信息1131。
[0095]
如该图所示，首先，可追踪性信息转换部118读出以设备供应者所制作的形式被制作的可追踪性信息30’，并转换为共通形式(s711)。
[0096]
图8是表示可追踪性信息30’及其转换的图。可追踪性信息30’是由可追踪性信息转换发送部212对可追踪性信息30进行转换而得到的信息。可追踪性信息30’a表示设备要求规格“req a
‑
l vl.0”通过设计“dsn yyy vl.0”和设计“dsn zzz vl.0”被满足。在此，
“
dsn yyy vl.0”和设计“dsn zzz vl.0”是由可追踪性信息转换发送部212转换后的表现。可追踪性信息30”是由可追踪性信息转换部118转换后的共通形式的信息。在使用rdf的情况下，信息通过由主语/谓语/宾语构成的句子被表现，在可追踪性信息30”中，“req a vl.0”是主语，“dsn yyy vl.0”和设计“dsn zzz vl.0”是宾语，表示“req a vl.0”通过“dsn yyy vl.0”和设计“dsn zzz vl.0”被满足的“被满足(satisfiedby)”是谓语。另外，在rdf中，将这些信息用uri(统一资源标识符(uniform resource identifier))表现。像这样，通过以rdf形式共通地管理可追踪性信息，能够利用查询语句sparql等，易于检索相关联的信息。
[0097]
返回图7，接下来，信息综合部114基于被转换为共通形式的可追踪性信息30”和可追踪性信息20，将在车辆提供者系统100及设备供应者系统200各自中被管理的信息(信息管理部111及法规信息管理部113各自所管理的信息)建立关联，从而生成车辆可追踪性信息40，该车辆可追踪性信息40是将法规id与“将法规要求信息22、车辆要求规格23、设备要求规格31、设计书32、源码33、软件37等以及法规要求信息22建立关联而成的信息”建立关联而成的信息(s712)。
[0098]
在接下来的循环处理s713s～s713e中，软件查询编号生成部115生成认可软件查询信息21。软件查询编号生成部115在每次循环中，顺次选择法规信息管理部113所管理着的法规信息1131的法规(法规id)。
[0099]
在上述循环处理s713s～s713e中，首先，软件查询编号生成部115将选择中的法规与软件查询信息管理部116所管理的车辆可追踪性信息40对照(s714)，经由车辆要求规格23、设备要求规格31取得与选择中的法规相关联的ecu，提取安装了该设备要求规格31的软件37的信息。在该法规仅与硬件相关联的情况下，不实施以后的处理，而结束处理(s715)。
[0100]
在循环处理s716s～s716e中，软件查询编号生成部115顺次选择s715中提取的与选择中的法规相关联的车辆可追踪性信息40，取得选择中的车辆可追踪性信息40所包含的软件id(s717)。
[0101]
如果上述循环处理s713s～s713e结束，则接下来，软件查询编号生成部115针对选择中的法规新发行(发号)软件查询编号，生成选择中的法规的法规id与新发行的软件查询编号所成的组(s718)。
[0102]
接下来，软件查询编号生成部115将s718中生成的法规id与软件查询编号所成的组，与s717中取得的全部软件id建立关联，来生成认可软件查询信息21(s719)。
[0103]
接下来，软件查询信息管理部116将s715中提取的全部车辆可追踪性信息40与s719中生成的认可软件查询信息21建立关联并作为管理对象(s720)。
[0104]
如上，车辆提供者系统100能够基于从设备供应者系统200送来的可追踪性信息30，高效地生成车辆可追踪性信息40以及认可软件查询信息21。
[0105]
＜软件查询信息的更新处理＞
[0106]
图9是说明在设备中装入的软件更新时车辆提供者系统100的软件更新管理部117所进行的处理(以下称为“软件更新管理处理s900”)的流程图。以下，结合该图关于软件更新管理处理s900进行说明。此外，设为在软件更新管理处理s900开始时，在可追踪性信息管理部110中，已注册(登记)了随着软件更新而被更新的可追踪性信息20(车辆提供者所生成的可追踪性信息)及可追踪性信息30’(从设备供应者系统200取得的可追踪性信息30’)。
[0107]
首先，软件更新管理部117从用户受理模型id(s911)。
[0108]
接下来，软件更新管理部117经由可追踪性信息转换部118及信息综合部114，使用新注册的可追踪性信息20、30’来更新车辆可追踪性信息40(s912)。
[0109]
接下来，软件更新管理部117提取更新前后的车辆可追踪性信息40的差异(s913)。差异的提取通过各要素中包含的版本的差异等而进行。作为差异的例子，例如，在由于问题等而修正了函数的情况下源码33产生差异，因此将其提取出来。
[0110]
接下来，软件更新管理部117提取与检测出差异的要素相关联的法规id(s914)。
[0111]
在接下来的循环处理s915s～s915e中，软件更新管理部117顺次选择被提取的法规id。
[0112]
在上述循环处理中，首先，软件更新管理部117针对选择中的法规id，使用更新后的软件id更新软件查询信息并进行注册(s916)。
[0113]
接下来，软件更新管理部117判定软件的更新对选择中的法规id的认可内容是否造成影响(s917)。在对认可内容有影响的情况下(s917:有影响)，处理向s918前进，在对认可内容无影响的情况下(s917:无影响)，处理向s915e前进，选择下一法规id并进行循环处理(s915s～s915e)。在此，影响的判断如下进行：对基于可追踪性信息从信息管理部111取得的规格信息及验证结果与从法规信息管理部113取得的申报完成文件所记载的内容进行比较，判断申报完成文件的内容是否需要变更。即，在申报完成文件的内容需要变更的情况下，判断为“对认可内容有影响”，在无需变更的情况下判断为“对认可内容无影响”。
[0114]
在s918中，软件更新管理部117对选择中的法规id的软件查询编号进行更新并注册。
[0115]
通过以上，用户能够有效地掌握与该软件更新相关联的或者需要更新的软件查询编号。
[0116]
此外，在s918中，例如也可以进一步提示与s914中取得的认可软件查询信息建立了关联的车辆可追踪性信息40所包含的信息。由此，用户能够参照与需要测试的软件相关的各种信息(法规要求信息22、车辆要求规格23、设备要求规格31、设计书32(基本设计书、详细设计书、测试规格书、测试结果等)、源码33、用于认可的提交文件，能够高效地推进测试作业。
[0117]
＜软件查询信息的参照处理＞
[0118]
图10是说明在参照软件查询信息时软件查询信息管理部116所进行的处理(以下称为“软件查询信息参照处理s1000”)的流程图。以下，结合该图关于软件查询信息参照处理s1000进行说明。
[0119]
首先，软件查询信息管理部116从用户受理模型id和键信息(s1011)。
[0120]
接下来，软件查询信息管理部116确认在用户的输入中是否指定了模型id(s1012)，在包含模型id的情况下(s1012：是)，处理向s1016前进，在不包含模型id的情况下(s1012：否)，处理向s1013s前进。
[0121]
在接下来的循环处理s1013s～s1013e中，软件查询信息管理部116顺次选择注册完成的全部模型id各自的车辆可追踪性信息40。
[0122]
在上述循环处理中，首先，软件查询信息管理部116判定选择中的车辆可追踪性信息40是否包含s1011中受理的键信息(s1014)。在包含键信息的情况下(s1014：是)，处理向
s1015前进。在不包含键信息的情况下(s1014：否)，处理向s1013e前进，选择下一车辆可追踪性信息40并进行循环处理(s1013s～s1013e)。
[0123]
在s1015中，软件查询信息管理部116取得与选择中的车辆可追溯性信息40建立了关联的模型id并进行显示，等待模型id的选择。
[0124]
接下来，软件查询信息管理部116根据与从用户输入的或者被选择的模型id对应的车辆可追踪性信息40，取得与上述被输入的键信息相关联的信息(法规id、软件查询编号、车辆要件、合格性验证结果报告书等)，并输出信息(s1016)。
[0125]
由此，用户能够根据指定的键信息容易地参照与软件相关的各种信息(法规要求信息22、车辆要求规格23、设备要求规格31等)，能够高效地推进软件更新时的影响分析、测试作业。
[0126]
＜用户界面＞
[0127]
在图11中，表示软件查询信息管理部116作为用户界面显示的菜单画面(以下称为“软件查询信息管理画面g800”)的一例。如该图所示，例示的软件查询信息管理画面g800具有关联信息查询按钮g810、新注册按钮g820、更新按钮g830。
[0128]
软件查询信息管理部116如果关联信息查询按钮g810被操作则显示图12所示的关联信息查询画面810，另外如果新注册按钮g820被操作则显示图13所示的软件查询信息新注册画面820，另外如果更新按钮g830被操作则显示图14所示的软件查询信息更新画面830。
[0129]
如图12所示，关联信息查询画面810具有模型id及键信息的输入栏811、检索结果的显示栏812。
[0130]
如果用户在键信息的输入栏811中输入了模型id和键信息，并操作了检索按钮8111，则软件查询信息管理部116受理模型id和键信息。软件查询信息管理部116使用与输入的模型id对应的车辆可追踪性信息40，从由键信息指定的函数取得与其相关联的各种信息，将取得的信息显示在检索结果的显示栏812中(此外，信息也可以作为链接被提供)。在输入栏811中未设定模型id的情况下，软件查询信息管理部116从全部车辆可追踪性信息中选择具有与其相关联的函数的车辆可追踪性信息，在检索结果的显示栏812中显示其模型id。
[0131]
如果模型id被选择，则软件查询信息管理部116使用与被选择的模型id对应的车辆可追踪性信息40取得各种信息并显示在检索结果的显示栏812中。各种信息包含法规id d211、软件查询编号d212、软件id d213、车辆要求规格23、系统综合验证结果报告书25、合格性验证结果报告书26、设备要求规格31、设备要求规格31、设计书32、源码33、单元验证结果报告书34、ecu综合验证结果报告书35及ecu合格性验证结果报告书36。
[0132]
如上，根据本实施方式的软件查询信息管理系统1，用户在更新了软件时，能够高效且切实地确定由于该更新而需要进行用于受到认可的测试的软件。另外，例如在软件跨车辆的模型被共用的情况下，能够跨车辆的模型来确定需要实施测试的软件。另外，用户能够使用被输出的认可软件查询信息21，高效地取得需要向政府报告的可追踪性信息、证据。
[0133]
如图13所示，软件查询信息新注册画面820具有模型id的输入栏821、生成结果的显示栏822。
[0134]
如果用户在模型id的输入栏821中输入了模型id，并操作了新注册按钮8211，则软
件查询信息管理部116受理模型id。
[0135]
软件查询信息管理部116使用与被输入的模型id对应的可追踪性信息20、30’，由可追踪性信息转换部118及信息综合部114生成车辆可追踪性信息40。接下来，由软件查询编号生成部115生成软件查询信息及软件查询编号。
[0136]
软件查询信息管理部116对于生成处理的结果以及生成的软件查询编号，在生成结果的显示栏822中输出信息。
[0137]
如上，根据本实施方式的软件查询信息管理系统1，用户能够在新开发了车辆时生成软件查询信息，高效地取得在认可时所需的软件的组合及其查询编号。
[0138]
如图14所示，软件查询信息更新画面830具有模型id的输入栏831、更新结果的显示栏832。
[0139]
如果用户在模型id的输入栏831中输入了模型id，并操作了更新按钮8311，则软件查询信息管理部116受理模型id。
[0140]
软件查询信息管理部116使用与被输入的模型id对应的可追踪性信息20、30’，由可追踪性信息转换部118及信息综合部114更新车辆可追踪性信息40。接下来，由软件更新管理部117更新软件查询信息及软件查询编号。
[0141]
软件查询信息管理部116对于更新处理的结果以及被更新的软件查询编号，在更新结果的显示栏832中输出信息。在本例中，表示为车辆可追踪性信息40、软件查询信息及软件查询编号均更新成功，而且作为虽然有可能受变更之处影响但未被更新的软件查询编号表示为“r13h001”，将实际上有影响而被更新的软件查询编号表示为“r7902002(更新)”。
[0142]
图15是在软件查询信息更新时在系统中未能判断软件查询编号是否需要更新的情况下的显示例。图15所示的例子除了更新结果的显示栏833以外与上述是同样的构成。在系统中未能判断软件查询编号是否需要更新的情况下，如图15的更新结果的显示栏833所示，表示车辆可追踪性信息40、软件查询信息已更新成功，表示软件查询编号的更新被保留。另外，将虽然有可能受变更之处影响但未能判断软件查询编号是否需要更新的表示为“r13h001(待定)”，将实际上有影响而被更新的软件查询编号表示为“r7902002(更新)”。
[0143]
如上，根据本实施方式的软件查询信息管理系统1，用户能够在更新了软件时更新软件查询信息，高效地更新在认可时所需的软件的组合及其查询编号。
[0144]
如以上详细说明的那样，根据本实施方式的软件查询信息管理系统1，能够使用认可软件查询信息21统一地管理软件查询信息6，能够高效地管理与针对车辆所搭载的设备中装入的软件的法定认可相关的信息。
[0145]
以上，关于本发明的实施方式进行了详述，但本发明不限定于以上说明的实施方式，包含在附带的权利要求书的主旨内的各种变形例及等同的构成。例如，上述的实施方式为了使本发明易于理解而详细说明，但本发明不限定于一定具备说明的全部构成。另外，也可以将某实施方式的构成的一部分置换为其他实施方式的构成。另外，也可以在某实施方式的构成中附加其他实施方式的构成。另外，也可以针对各实施方式的构成的一部分，追加、删除或者置换其他构成。
[0146]
在本发明的说明中，作为组件表示了ecu的事例，但也有时不仅是车载ecu，而且还与车辆外配置的服务器装置协作来构成法规要求、系统要求。在该情况下，系统要求被分解为对服务器装置的要求和对车辆的要求，对车辆的要求被分解为进一步的对ecu的要求。但
是，在要求面向服务器装置的情况下，可以认为在这样的情况下也能够将上述的设备要求规格31视为对服务器装置的要求，并进行同样的管理。即，关于跨车辆和服务器装置的功能，也能够统一地进行对于认可的影响分析等。
[0147]
在上述的发明中，表示了可追踪性信息转换部118被配置于车辆提供者系统100的例子，但也可以配置于设备供应者系统200的可追踪性信息转换发送部212。通过像这样，车辆供应者能够以统一的格式接收可追踪性信息。
[0148]
另外，上述的各构成、功能、处理部、处理机构等既可以通过将其一部分或者全部例如在集成电路中设计等而以硬件实现，也可以通过处理器解释并执行用于实现各个功能的程序而以软件实现。
[0149]
实现各功能的程序、表、文件等的信息能够存放于存储器、硬盘、ssd(固态驱动器(solid state drive))等存储装置、或者ic(集成电路(integrated circuit))卡、sd卡、dvd(数字通用盘(digital versatile disc))等记录介质。
[0150]
控制线、信息线示出了认为在说明上需要的对象，但不限于示出了在安装上需要的全部控制线、信息线。也可以认为在实际上几乎全部构成都相互连接。