监控组件由五个模块组成: 程序寄存器那 程序信息接收方那 系统信息采集者那 数据协调， 和 第三方模块．程序寄存器和程序信息接收者负责收集有关应用程序的信息。在执行应用程序期间，两个模块连接到TCP / IP中的应用程序。例如，当在系统上执行自适应应用程序时，该应用程序通过程序寄存器在自适应软件框架的轻量级和多功能监视器中登记;然后，程序信息接收机收集有关注册应用程序的静态/动态信息。桌子 1提供正在运行的应用程序的静态/动态信息的摘要。

系统信息收集器实时收集有关系统资源的静态/动态信息。此外，第三方模块从外部模块或外部设备接收诸如电源，程序特征和内部内核信息的信息。例如，系统电源和应用功率必须通过外部电源设备测量，测量的电源被传送到自适应系统观察监视器的第三方模块。系统静态信息表示与HW资源相对应的固定值（例如，CPU，CPU，内存和网络），并且在系统功能时仅配置一次。通常，当HW细节保持不变时，系统静态信息对系统具有唯一的值。该值由一次性数据收集确定。系统动态信息表示根据系统状态更改的值。这些值中的大多数可以根据系统开销而变化，并且在设置信息收集的设置期间定期更新它们。表中显示的系统静态信息 2包括CPU核心，CPU频率，内存，网络和DVF。系统静态信息是HW的固定信息。如果HW功能发生变化，则系统静态信息也会更新。对于该信息，对应于每个HW系统的数据结构是单独维持的。当执行轻量级和多功能监视器时，系统静态信息仅更新一次。表中显示的系统动态信息 2包括CPU内核，CPU利用率，存储器，网络和电源的当前状态。可以根据系统的当前状态来改变动态信息;此外，用户可以改变系统的资源值，因此，动态信息在实时改变。

数据协调器将从程序信息接收者、系统信息收集者、第三方模块收集到的信息进行重组;然后，将这些信息保存在应用信息DB和系统信息DB中。应用程序和系统的动态信息分为两种数据结构:即时数据和计算数据。即时数据(如CPU活动)可以立即在其他模块中使用，而计算数据(如利用率)由于需要额外的操作而不能立即使用。关于应用程序和系统的静态信息具有单一的数据结构，该结构对应于即时数据。这些数据实时分为应用、系统和第三方数据。

控制组件由四个模块组成： CPU控制那 记忆控制那 网络控制， 和 控制执行．此组件提供了控制系统资源（如CPU，内存和网络）的环境。这些系统资源的各种参数如下： （一世）

CPU：核心开/关，核心频率，螺纹亲和力，DVFS（动态电压频率缩放）[ 4.]

控制执行通过与proc文件系统交互来控制CPU和内存。控制执行通过使用网络控制命令(例如，tc命令)或内核模型程序(例如，网络堆栈)来控制网络。此外，控制组件提供监视接口和控制接口，如库。桌子 3.显示监控接口和控制接口。因此，自适应系统观察使用关于应用程序和系统的静态/动态信息来实现应用程序的最佳执行。

数字 3.显示具有自适应SW框架的视频传输系统，包括轻量级和多功能监视器。该系统由三层结构组成（IoT设备 ↔ 机顶盒（STB） ↔ 主机系统)。执行视频捕获和编码的物联网设备由Intel Edison Board组成[ 5.- 8.]有凸轮;执行视频流的STB由带有Exynos 5422的嵌入板组成[ 9.]并包含所提出的监视器和自适应政策经理。此稿件未关注政策经理。包括用户界面的主机系统由具有诸如Wi-Fi的无线通信的移动设备组成。该系统的功能可以描述如下：使用凸轮实时从英特尔爱迪生板生成视频源;通过Wi-Fi将所产生的源传送到STB;STB上的视频流服务器接收这些视频源并实时解码它们;最后，解码源通过Wi-Fi传送到移动设备。

在图中 3.，如果机顶盒中没有自适应的SW框架，则由于开销的原因，机顶盒可能会将由Intel Edison Board生成的高比特率视频转换为低比特率视频，因此机顶盒无法保证将其传输到主机系统。在典型的系统中，可以观察到这种行为。然而，即使机顶盒中存在自适应SW框架，由Intel Edison Board生成的高比特率也可能无法到达物联网设备和主机系统。例如，在视频源数量稳定增加的情况下，典型的视频传输系统很难将Edison Board生成的高比特率视频提供给移动设备。原因是流媒体服务器中分配的系统资源(如内核数、内存、网络带宽等)不足;因此，机顶盒以公平的方式将低性能分配给运行的应用程序。然而，本文所提出的视频传输系统能够向移动设备提供高比特率的视频，因为我们的系统采用了一个包含轻量级和通用监视器的自适应软件框架中间件。这个中间件可以使用监视器收集的应用程序和系统信息来处理系统资源。因此，在开销较大的情况下，该系统始终保持用户定义的QoS。

数字 4.展示了基于数字实施的系统 3.．在图中 4.，两个爱迪生板捕获和编码视频图像。嵌入式电路板收到这些图像并处理它们。轻量级和多功能的监视器移植到电路板上。在笔记本电脑中运行的工具显示了实时监视器收集的信息;该信息表示有关视频流服务器和嵌入式电路板的静态/动态信息。移动设备提供有目标系统的原始图像而不会损失图像。工具和UI（用户界面）显示了常规QoS，由图中的红色表示。

为了验证所提出的监视器的轻量级特性，在exynos 5422嵌入式系统上函数，我们使用我们的自主实验应用来测量监视器的CPU利用率。应用程序自动创建根据输入值的进程，然后启动进程的执行。输入值为1,7,5,30,50,80,100,130,170和200. CPU利用率由DVFS调速器（交互式，性能和onDemand）测量。图 5.那 6.， 和 7.显示CPU利用率对应于监视器中的运行进程数分别用于DVFS的交互式，性能和ondemand模式。每个图中的顶部图显示了与CPU利用率转换为200个运行进程的百分比的结果。在执行进程正在执行时，CPU利用率测量为500次。这些图中的底部图显示了根据受监视过程的数量的CPU利用率的平均和误差范围。

对于交互式模式，测量到的CPU利用率在图的顶部图形中以百分比显示 5.．如图所示，百分比大约为50个过程，百分比约为20％。然而，超过80个进程超过30％，因此建议的监视器由于其监测开销而可能影响嵌入式系统（例如，Exynos 5422）。图的底部图 5.是前述事实的详细实验结果。该图表明，在交互模式下工作的监视器的CPU利用率系数为1.2662（ y = 1.2662 x - 0.6052 ）.该系数由基于进程数的实测CPU利用率的回归分析结果计算得出。这个结果是正确的，因为 R. 2 ，测量数据的可靠性为0.9658。在图的底部图 5.，CPU利用率约为4％，最多为50个进程，如虚线红色矩形所示。因此，我们可以说明所提出的监视器具有轻量级特性，因为大量过程（大于50）的基于自适应SW框架的显示器不是必需的。结果在图中 6.和 7.与图的结果类似 5.．CPU利用系数为1.1602（ y = 1.1602 x - 1.2507 ） 和 R. 2 是0.9923。CPU利用率也大约为50个进程约为4％。图中的CPU利用系数 7.是1.6026（ y = 1.6026. x - 0.2901 ） 和 R. 2 是0.9905。但是，CPU利用率约为50个进程。通过实验结果，所提出的监视器显示了性能模式中最好的CPU利用率和交互模式下的第二个最佳CPU利用率。OnDemand模式具有比性能和交互式模式更多的开销，因为模式通过定期检查CPU利用率来控制CPU频率。

数字 8.显示对应于交互式，性能和onDemand模式的进程数（1,7,15和50）的CPU利用率。在所有四个图中，OnDemand模式的CPU利用率非常广泛波动，并且利用率也高于交互式和性能模式的利用率。随着进程的数量增加，建议的监视器在ondemand模式下有更多的开销。（例如，“#process 50通过DVFS”图形图 8.表示ondemand模式的CPU利用率超过交互式和性能模式的2倍）。也就是说，监视器有效地在交互式和性能模式下工作。总的来说，OnDemand模式比交互式和性能模式更大的开销。数字 9.良好地解释上述逻辑原因。在性能中，当过程数量为1时，CPU利用率为0.49。在这种情况下，建议的监视器具有最大的性能。当过程数量为50时，CPU利用率为3.95.利用率的增加率约为8.06。增加差距是DVFS调速器的CPU利用率中最大的差距。在交互模式下，当过程数量为1时，CPU利用率为2.04，当过程数量为50时，CPU利用率为4.50.利用率的增加率约为2.21。增加的差距是最小的，因此建议的监视器具有最稳定的性能。在ondemand模式下，当过程数量为1时，CPU利用率为1.99，当过程数量为50时，CPU利用率为7.03。在这种情况下，建议的监视器具有最糟糕的性能。利用率的提高率约为3.53。因此，监视器在性能模式下具有轻量级开销，并且监视器在交互模式下具有最稳定的开销。