一种基于MBSE的轨道交通智慧乘客信息系统建模方法

技术领域

本发明涉及轨道交通信息服务领域，特别是涉及一种基于MBSE的轨道交通智慧乘客信息系统建模方法。

背景技术

当前，乘客对于城市轨道信息服务的要求越来越高，这就要求乘客信息系统(PIS)的更新换代更快，同时PIS的功能又存在相互独立、集成化程度不高、研发效率较低、研发周期长、系统复杂的特点。传统的研发过程，通常用文档的方式保存技术文件，容易对系统造成，需求重复，功能交叉等问题。为解决上述问题，将PIS的三个功能进行模块化处理提出智慧乘客信息系统(IPIS)，采用MBSE思想对IPIS进行建模。

MBSE是一种用模型驱动系统的建模思想，可以使建模方法支持系统的要求、设计、分析、验证和确认等活动，现阶段广泛应用于大型的复杂系统和软件开发项目，面向不同的复杂系统和工业领域有不同的方法、语言和工具。相对主流的方法有Object-OrientedSystems Engineering Method(OOSEM),Rational Integrated Systems/EmbeddedSoftware Development Process Harmony(Harmony SE),Arcadia,Magic Grid等方法，建模工具有Vitech CORE、Cameo Systems Modeler、Visual Paradigm、M-Design等，常用的建模语言有Simulink、STATEMATE、UML、SysML。

MBSE促进了参与系统设计过程的不同团队和不同利益相关方之间的合作。MBSE以模型为中心，利用形式化语言建模，可以实现一致理解、多专业沟通，可仿真、可验证、可确认，实现需求条目化表达与追溯以及需求与设计变更影响分析。

高金艳等公开了一种基于MBSE的火星维护和管理装置的方法(火星维护与管理装置的MBSE架构建模(高金艳,汪路元,潘忠石等.火星维护与管理装置的MBSE架构建模[J].系统工程与电子技术,2023,45(05):1441-1450.)，此方法从顶层用户需求出发，完成了对该装置的总体设计。具体包括用户需求分解、系统任务定义、逻辑功能分解、系统物理实现和指标参数约束5个方面。在火星维护与管理装置的各个设计阶段，给出了SysML模型。由于面对的对象不同，此方法只适用于火星维护与管理装置。

目前尚未见到基于MBSE的PIS建模方法的报导。

发明内容

为解决现有技术存在的问题，本发明目的是提供一种适用于轨道交通智慧乘客信息系统的建模方法，该方法能避免文字的二义性、减少冗余、降低成本、缩短设计周期能、提高研发效率。

为此，本发明采用以下技术方案：

一种基于MBSE的轨道交通智慧乘客信息系统建模方法，包括以下步骤：

S1，利益相关方分析：利用SysML中的模块定义图，从IPIS的应用人员角度进行分析，

确定各利益相关方；

S2，涉众需求分析：包括涉众需求识别、分层分类、唯一ID标识、相似需求整合，用需求图和需求表清晰表示，确保充分考虑各利益相关方的期望；

S3，用例和用例场景分析：

对S2得到的涉众需求进行分析，推荐适合的用例；对推荐的用例进行判断，识别出功能性用例；通过分析所述功能性用例和IPIS系统进行交互的外部系统间的关系，得到用例场景；

S4，黑盒活动分析，包括以下步骤：

S41，输入用例并进行分析：

将步骤S3输出的功能性用例作为输入，对其进行分析，通过专业知识、查询相关文献，将功能性用例通过黑盒活动图的方式描绘出来；

S42，划分泳道：

根据动作发出者的不同，利用泳道将黑盒活动图中的活动分配给本系统、其它系统或利益相关方，所述其它系统包括TCMS或者ATC；在IPIS泳道内的活动就是IPIS的功能点，将其作为S5的输入；

S5，进行白盒活动分析，包括：

S51，根据所述IPIS的功能点包含的关键词在行为库中搜索相对应的活动；

S52，判断S51搜索到的活动能否进行再利用，如果能再利用，就将该活动作为蓝本进行适当的修改，作为当前功能点的白盒活动；否则，通过查阅相关资料、咨询专家的方式直接进行白盒活动分析，得到当前功能点的白盒活动；将得到的白盒活动存入所述行为库中；

S6，功能分析：对S5得到的白盒活动进行聚类分析，将一个或几个白盒活动抽象成一个功能；

S7，系统架构设计：基于S6得到的功能对IPIS系统进行架构设计。

优选的是，在进行S7的系统架构设计前还进行系统需求分析：将S2得到的涉众需求进行整合、归纳并进一步细化得到系统需求，将所述系统需求与S6得到的功能通过追溯矩阵进行追溯，确保所述系统需求和功能够准确、完整、一致地被追溯到；在进行S7的系统架构设计时，基于所述系统需求分析和S6得到的功能对IPIS系统进行架构设计。

上述的步骤S2包括以下分步骤：

S21，需求识别：通过与各利益相关方进行面谈、问卷调查、小组讨论的方式识别出各利益相关方对IPIS的需求，将这些需求以“作为某某利益相关方，我希望可以XXX”的句式进行表述；

S22，需求标识和分层：

将识别出的需求进行分层，通过为每个需求分配唯一的ID，标识出每个涉众的需求；将这些需求按照不同的利益相关方进行分类。

优选的是，步骤S2还包括分步骤S23，进行需求整合和筛选：利用AI识别技术对已识别的需求进行处理，将相同或相似的需求进行筛选和整合，以减少冗余需求，确保需求的清晰性和一致性。

上述的步骤S3包括以下分步骤：

S31，功能性用例的产生，包括：

S311，利用语义识别推荐用例：利用语义识别技术对S2得到的涉众需求进行分析，推荐适合的用例；

S312，用例的判断：对于推荐的用例，使用AI技术来判断是否为功能性用例；将推荐的用例根据层级进行记录，如果是功能性用例，执行S314；否则，执行S313；

S313，用例筛选：通过语义识别继续推荐下一层的用例，然后返回S312；

S314，输出所述功用性用例；

S32，用例场景分析：通过分析S314输出的功能性用例和IPIS系统进行交互的外部系统间的关系，得到用例场景。

步骤S312记录下的用例和S32得到用例场景分别分为四层，具体如下：

顶层用例和用例场景：

通过语义识别推荐出正常、异常、维护三个顶层用例并将正常用例和异常用例结合，得到IPIS使用和IPIS维护两个顶层用例，在SysML中用椭圆进行表示；

分析哪些利益相关方或外部系统和IPIS有交互；将IPIS系统和外界系统或利益相关方的关系利用SysML中的“关联”关系进行表达，构成顶层的用例场景；

第二层用例和用例场景：

将顶层用例中的非功能性用例展开，得到第二层用例，同样在SysML中用椭圆进行表示；

将顶层用例中的非功能性用例作为系统边界，利用虚线进行表示，将与该顶层用例相关的利益相关方和外部系统通过“关联”进行表达，与第二层用例共同构成第二层用例场景；

第三层用例和用例场景：

对第二层用例进行细化，得到部分功能性用例，将细化得到的所有用例均作为第三层用例；

该层用例和第四层用例共用同一用例场景；

第四层用例和用例场景：

继续分解第三层用例中的非功能性用例，将得到的功能性用例作为第四层用例；

将第二层用例的非功能性用例作为系统边界，利用模块表示；将第三层用例中的功能性用例与第四层用例以及与它们相关的利益相关方和外部系统通过“关联”进行表达，共同构成底层用例场景。

优选的是，在步骤S6中先构建一个功能元模型，该功能元模型包含功能和功能组两个构造型，所述功能和功能组是泛化的关系；所述功能元模型包含优先级和功能描述两个属性；利用该功能元模型对S5得到的白盒活动进行聚类分析，将一个或几个白盒活动抽象成一个功能。优选的是，根据IPIS中广播内容的重要程度设置所述优先级，高优先级能够打断低优先级的广播顺序，高优先级的播放完毕后自动退回低优先级的广播选区。

本发明基于MBSE经典方法和IPIS特点，提出了适用于IPIS建模的新方法，从利益相关方、涉众需求、用例场景等方面完成对复杂系统的设计。与现有技术相比，本发明具有以下有益效果：

1.本发明通过对PIS的三个功能进行模块化处理，提高了IPIS的灵活性和可维护性，同时使系统更容易扩展和升级。IPIS有更强的智能化和自动化功能，有望为乘客提供更优质、便捷的信息服务。

2.本发明采用基于模型的系统工程方法，有助于更好地理解、设计和管理IPIS系统，从而提高了系统的整体一致性、可靠性和效率。MBSE通过提供更好的可视化、集成和协作工具，加速了复杂系统的开发和管理过程，同时降低了风险并提高了项目的成功率。通过使用适用于轨道交通智慧乘客信息系统的建模方法，可以更高效地识别、整合和分类涉众需求，从而加速研发过程。

3.本发明提出了适用于IPIS建模的新方法，并且利用人工智能和文字识别快速根据需求推荐用例和活动，整合相似需求，减少冗余，有助于减少研发过程中的重复劳动和资源浪费，从而降低了研发成本。通过建立IPIS系统的性能元模型、功能元模型和系统需求元模型，提高了模型的重用率提高了，缩短了整体的设计周期。

4.本发明提出了一种基于SysML的IPIS系统建模方法，其中系统的最小功能点的活动被称为元活动。为了实现更高效的建模，本方法提出了轨道交通相关的其它系统中的元活动构成的一个行为库，这些其它系统可以包括牵引系统、屏蔽门系统、FAS系统等。

附图说明

图1为本发明的建模方法流程图；

图2为本发明一个实施例中的利益相关方；

图3为本发明一个实施例中的总需求图；

图4为本发明一个实施例中的局部需求表；

图5为本发明一个实施例中的顶层用例分解；

图6为本发明一个实施例中的智慧乘客信息系统正常使用下的用例；

图7为本发明一个实施例中的广播应用下用例；

图8为本发明一个实施例中的广播方式活动图；

图9为本发明一个实施例中的播放预录制内容活动图；

图10为本发明一个实施例中的全自动广播白盒活动图

图11为本发明一个实施例中的功能元模型；

图12为本发明一个实施例中的广播单元功能图；

图13为本发明一个实施例中的广播单元的系统级需求图；

图14为本发明一个实施例中的系统需求和功能分析图；

图15为本发明一个实施例中的系统需求和功能的追溯(每个功能对应的需求)图；

图16为本发明一个实施例中的子系统分析图；

图17为本发明一个实施例中子系统间的交互图；

图18为本发明一个实施例中广播单元和广播系统的映射关系图；

图19为本发明一个实施例中的系统架构图。

具体实施方式

以下结合附图和实施例对本发明的建模方法和建模系统进行详细说明。

参见图1，本发明的基于MBSE的轨道交通智慧乘客信息系统建模方法包括八个步骤，其中，S1-S4在黑盒视角下(B层)进行，S5-S8在白盒视角下(W层)进行。具体如下：

S1，利益相关方分析：

利用SysML中的需求图，从IPIS系统的应用人员角度分析利益相关方有那些。通过查阅资料、实地考察确定利益相关方有哪些，以便给步骤S2的涉众需求进行分析进行铺垫。

智慧乘客信息系统的利益相关方包括5个，如图2所示，分别为司机、运营控制中心、乘客、车站工作人员、公安系统。

S2，涉众需求分析：包括涉众需求识别、分层分类、唯一ID标识、相似需求整合，通过需求图和需求表清晰表示，确保充分考虑各利益相关方的期望。具体包括：

S21，需求识别：

通过与各利益相关方进行面谈、进行问卷调查以及组织焦点小组讨论等方式，识别出各利益相关方对IPIS的需求，将这些需求以“作为某某利益相关方，我希望可以XXX”的句式进行表述。

S22，需求标识和分层：

通过为每个需求分配唯一的ID，标识出每个涉众的需求。将这些需求按照不同的利益相关方进行分类，并在需求图和需求表中使用相关的属性来标注。

为了更加清晰地表达上述涉众需求，将上述需求进行分层。

在本发明的一个实施例中，将所述需求分为三层，具体如下：

第一层用ID＝“R-X”表示。第一层是每个相关方对IPIS的需求，其中R表示需求；X表示相关方的序号。

第二层用ID＝“R-X.X”表示。第二层是某个具体的利益相关方的主要需求。

第三层用ID＝“R-X.X.X”表示。第三层是在第二层的基础上，更加有针对性的提出需求。

上述每一层都通过Text＝“……”的形式对具体需求进行描述。

通过图3的需求图和图4所示的需求表对利益相关方的需求进行详细描绘。

例如，在对ID＝“R-1.1”，Text＝“两端司机室对讲，司机与乘客对讲，司机与控制中心对讲”这一项需求进行细化时，从“两端司机室对讲”、“司机与乘客对讲”、“司机与控制中心对讲”、“司机与车站工作人员对讲”四个方面进行细化。“两端司机室对讲”这一需求的内容为“作为司机，我希望可以和两端司机室对讲”；“司机与乘客对讲”这一需求的内容为“作为司机，我希望可以乘客对讲”；“司机与控制中心对讲”这一需求的内容为“作为司机，我希望可以和控制中心对讲”；“司机与车站工作人员对讲”这一需求的内容为“作为司机，我希望可以和车站工作人员进行对讲”。

S23，需求整合和筛选：

利用AI识别技术对已识别的需求进行处理，将相同或相似的需求进行筛选和整合，以减少冗余需求，确保需求的清晰性和一致性。

通过以上步骤能够将涉众的需求进行详细的整理和分析，确保每个利益相关方的期望都得到了充分的考虑。同时，利用SysML中的需求图，能够以图形化的方式清晰地表示各个需求的关系和属性，为后续的系统设计和开发提供准确的指导。

S3，用例和用例场景分析，包括：

S31，功能性用例的产生，具体如下：

S311，利用语义识别推荐用例：利用语义识别技术对S2得到的涉众需求进行分析，推荐适合的用例。

S312，用例的判断：对于推荐的用例，使用AI技术来判断是否为功能性用例(即带有功能性质的用例)。将推荐的用例根据层级进行记录，如果是功能性用例，执行S314；否则，执行S313；

S313，用例筛选：通过语义识别继续推荐下一层的用例，然后返回S312。

S314，输出所述功用性用例。

S32，用例场景分析；

通过分析S314输出的功能性用例和IPIS系统进行交互的外部系统间的关系，得到用例场景。

通过上述流程，我们能够结合语义识别和SysML中的用例图，将涉众需求转化为系统功能性用例。通过这一流程，我们可以更准确地识别和整理系统的功能需求，确保每个涉众的期望都得到满足。

在本发明的一个实施例中，将S312记录下的用例和S32得到用例场景分别分为四层，具体如下：

1.顶层用例和用例场景：

通过语义识别推荐出来了正常、异常、维护三个顶层用例。由于本系统的特殊性，将正常和异常进行结合，形成IPIS系统的用例，即，顶层用例包括IPIS使用和IPIS维护，在SysML中用椭圆进行表示如图5所示。

在建立完顶层用例后，分析哪些利益相关方或外部系统和IPIS有交互。其中，乘客、司机、车站工作人员、运营控制中心、公安系统、TCMS-地铁车辆控制及监控系统、ATC-列车自动控制系统均为与系统有关联的外部利益相关方或系统。将IPIS系统和外界系统或利益相关方的关系互利用SysML中的“关联”关系进行表达，构成顶层的用例场景。

2.第二层用例和用例场景：

经过AI判断“IPIS使用和IPIS维护”不是功能性用例，因此继续通过语义识别推荐用例。

将顶层用例中的非功能性用例展开，得到第二层用例，同样在SysML中用椭圆进行表示；将顶层用例中的非功能性用例作为系统边界，利用虚线进行表示，将与该顶层用例相关的利益相关方和外部系统通过“关联”进行表达，与第二层用例共同构成第二层用例场景。

例如，将用例“IPIS使用”展开，得到PA(Public Address，公共广播)应用、CCTV(Closed Circuit Television，监控)应用和PIDS(Passenger Information DisplaySystem，显示)应用三个用例。这三个用例的共同点是在涉众需求的描述下概括出来的，这三个用例场景包含了S2提到的需求，同样是用SysML中用椭圆进行表示，如图5所示。

将IPIS使用作为系统边界，利用虚线进行表示，将与“IPIS使用”用例相关的利益相关方和外部系统通过“关联”进行表达，与第二层用例一同构成第二层用例场景。

3.第三层用例和用例场景：

对第二层用例进行细化，得到部分功能性用例，将细化得到的所有用例均作为第三层用例。

如图6中的“ID1.1广播内容”、“ID1.2广播方式”、“ID1.3对讲”、“ID1.4乘客按下紧急按钮情况时录音”均为第三层用例。在用例图下的“IDX.X”仅仅用来区分第三层和第四层用例，在此步骤中要注意和步骤S2的需求ID定义区分。这四个用例的共性是它们都跟广播相关。

该层和第四层共用同一用例场景。

4.第四层用例和用例场景：

由于在第三层只有部分用例可以分解得到功能性用例，在本层需要继续分解第三层用例中的非功能性用例。因此，通过查阅相关技术资料等方式将所述非功能性用例进行细化分解，将得到的功能性用例作为第四层用例。

将第二层用例的非功能性用例作为系统边界，利用模块表示；将第三层用例中的功能性用例与第四层用例以及与它们相关的利益相关方和外部系统通过“关联”进行表达，共同构成底层用例场景。

如图6所示，ID1.1中包含“ID1.1.1预录制内容播放”，“ID1.1.2话筒直接播放(应急广播)”。ID1.2包含“ID1.2.1全自动播放站名及注意事项”，“ID1.2.2半自动播放站名及注意事项”，“ID1.2.3人工广播站名及注意事项”等第四层用例。ID1.3包含“ID1.3.1两端司机室对讲”，“ID1.3.2司机与乘客对讲”等第四层用例。在第四层得到的用例都是功能性用例，加上第三层的部分在“PA应用”下的用例，一共得到8个功能性用例

将“PA应用”作为系统边界，利用模块表示，将与“PA应用”用例相关的利益相关方和外部系统通过“关联”进行表达，与8个功能性用例一同构成底层用例场景。

将上述四个步骤描述清晰后，便得到了完整的用例模型。

S4，黑盒活动分析：

此步骤是B层的最后一步，也是最为关键的一步。通过分析黑盒活动，在此步骤可以得到一个黑盒行为模型。利用SysML中的活动图构建黑盒行为模型，此时的活动是IPIS和TCMS、ATC两个外部系统的交互，同时在IPIS泳道内识别出来IPIS的功能点。包括以下分步骤：

S41，输入用例并进行分析：

将步骤S3输出的功能性用例作为输入，对其进行分析。通过专业知识、查询相关文献等方式，将功能性用例通过黑盒活动的方式描绘出来。黑盒活动指的是IPIS系统应该做哪些活动。

对部分的用例进行黑盒活动分析，以ID1.2广播方式的黑盒活动为例，如图8所示，分析过程如下：

开始，系统上电自检10秒，判断系统是否正常，正常的话进入判断广播方式，TCMS、ATC给智慧乘客信息系统输入信息，触发判断广播方式的活动内容。如果ATC和和TCMS正常触发人工广播，则进行人工广播，结束。

以ID1.1.1预录制内容播放进行黑盒活动为例，如图9所示，分析过程如下：

开始，智慧乘客信息系统接收来自TCMS发来的GPS的定位信息。判断列车是否到达本站，如果到达本站，判断是否越站，如果没有越站，司机发送播放请求，触发预录制到站广播信息，司机选择要播放的语言智慧乘客信息系统，播放预录制内容，判断列车是否到达终点站，若到达终点站，则结束。将不同的活动分配到不同的泳道中，执行不同的活动。

S42，划分泳道：

根据动作发出者的不同，利用泳道将黑盒活动图中的活动分配给本系统、其它系统或利益相关方。所述其它系统包括TCMS或者ATC；在IPIS泳道内的活动就是IPIS的功能点，将其作为S5的输入。

黑盒活动图中的活动可以被分成为几个区域，每个区域在图中用虚线分开，称为泳道。泳道是活动图的内容的组织单元。它没有内在的语义，但可以根据建模者的意愿使用。通常，每个泳道代表真实世界组织内的一个组织单元。

S5，进行白盒活动分析：

系统的最小功能点的活动被称为元活动。为了实现更高效的建模，本方法将轨道交通相关的其它系统中的元活动构成一个行为库。这些其他系统可以包括牵引系统、屏蔽门系统、FAS系统等。

白盒活动分析的过程如下：

S51，根据所述IPIS的功能点包含的关键词在行为库中搜索相对应的活动；

S52，判断S51搜索到的活动能否进行再利用，如果能再利用，就将该活动作为蓝本进行适当的修改，作为当前功能点的白盒活动；否则，通过查阅相关资料、咨询专家的方式直接进行白盒活动分析，得到当前功能点的白盒活动；将得到的白盒活动存入所述行为库中。

参见图10，例如：ID1.2广播方式中的触发全自动广播的白盒活动，由于该活动未在行为库中被搜索到，因此直接进行建模。建模过程如下：

外部系统向智慧乘客信息系统输入触发信号-触发全自动广播-预先播放到站信息-播放下一站到站信息-播放开门信息-播放关门信息，结束。

采用这种方式，本方法能够显著减少建模所需的时间和工作量。通过直接借鉴行为库中的元活动，可以避免从零开始构建功能点的活动图，从而提高建模的效率和质量。这种方法还可以确保系统中的不同功能在建模时保持一致性，因为行为库中的元活动是经过验证和测试的，可以为不同功能提供可靠的基础。最终，这种基于行为库的建模方法有助于实现更快速、更准确的建模，从而加速系统设计和开发的进程。

S6，功能分析：对S5得到的白盒活动进行聚类分析，将一个或几个白盒活动抽象成一个功能。

由于现有的SysML构造型是无法实现IPIS系统功能描述的，所以先构建一个功能元模型，如图11所示，该功能元模型内包含功能和功能组两个构造型，所述功能和功能组是泛化的关系；所述功能元模型包含优先级和功能描述两个属性；利用该功能元模型对S5得到的白盒活动进行聚类分析，将一个或几个白盒活动抽象成一个功能。

由于智慧乘客系统中广播的特殊性，因此根据IPIS中广播内容的重要程度设置了优先级，高优先级可以打断低优先级的广播顺序，高优先级的播放完毕后自动退回低优先级的广播选区。

通过对S5的白盒活动进行聚类分析得到功能，如图12所示。例如，ID1.2广播方式的触发全自动广播所包含的活动进行预先播放到站信息，播放下一站到站信息，播放开门信息，播放关门信息，将上述活动聚类分析，就可以得到“全自动广播”功能，其中优先级为5，功能描述为1、预到站广播(离站广播)2、到站广播。

整个广播功能包含下面的功能：控制中心对列车的广播、人工广播、两端司机室对讲、半自动广播、全自动广播、广播的输出控制、客室广播音量自动调节、主副台设置冗余控制功能、乘客紧急报警对讲录功能、预录紧急广播信息紧急播放功能。

S7，系统需求分析：将S2得到的涉众需求进行整合、归纳并进一步细化，得到系统需求，将所述系统需求与S6得到的功能通过追溯矩阵进行追溯，确保所述系统需求和功能够准确、完整、一致地被追溯到。

如图13所示，将涉众需求进行聚类，最终得到了广播系统的6大系统需求。最后进行追溯验证，如图15所示，确保每个功能都能被追溯上。

系统需求阶段，通过S6得到的功能进行聚类分析，得到系统需求，对于系统需求如图13所示对于广播的系统级需求包含ID1.1存储需求，ID1.2对讲，ID1.3广播输出控制，ID1.4无线电广播，ID1.5数字化报站/关门报警，ID1.6监听。

对于系统需求和功能的关系，如图14表示，实现“客室紧急报警对讲录音”功能，系统需要满足存储需求，对讲需求。实现“两端司机室对讲”功能，系统需要满足对讲需求。实现“广播输出控制”功能，系统需要广播输出控制需求。实现“控制中心对列车的广播”功能，系统需要满足无线电广播需求。实现“全自动广播”“半自动广播”“人工广播”功能，系统需要数字化报站/关门报警需求。实现“广播监听”功能，系统需要满足存储需求，监听需求。其中系统需求和功能的追溯图如图15所示。

S8，系统架构分析：基于所述系统需求分析和S6得到的功能对IPIS系统进行架构设计。

通过对智慧乘客信息系统进行系统架构分析，最终得到三大子系统：广播子系统、显示子系统和监控子系统。

将IPIS系统分解为CCTV监控单元、PA广播单元；PIDS显示单元如图16所示。通过内部模块定义图，对每个子系统间的交互进行描述，如图17所示。通过对广播单元的功能分析、系统需求分析将广播单元分为播报系统、对讲系统、控制系统和紧急系统，通过映射将广播单元映射到系统层面为广播系统，如图18所示。

在IPIS子系统间的关系如图17所示。IPIS系统由广播系统、显示系统、监控系统三个子系统组成，其中由电源模块为其供电，通过音频端口，将音频信息进行传输，通过控制端口将输入输出信号进行传输，通过视频端口传输视频信号，最终得到图19所示的系统架构。