apollo：Monitor模块如何监控硬件

OceanStar的学习笔记

已于 2023-03-01 19:30:39 修改

阅读量743

点赞数

分类专栏： ROS 文章标签：网络自动驾驶 linux

于 2021-05-13 15:24:20 首次发布

原文链接：https://www.linuxprobe.com/effective-c-pdf.html

版权

ROS 专栏收录该内容

84 篇文章 51 订阅

订阅专栏

概述

前面的文章有分析，Monitor 模块监控的内容分为 Hardware 和 Software 两位。

本篇分析硬件监控部分。

首先，可以观察一下 Apollo 官方文档给出的硬件连接图。

在这里插入图片描述
跟自动驾驶本身相关的无非是传感器和底盘

在这里插入图片描述
当前 Monitor 系统支持的硬件类监控有 4 个：

ESD CAN
GPS
Resource
SOCKET CAN

EsdCanMonitor

ESD CAN 是一种 CanCard，在 Apollo 中通过 PCIe 接口连接到 6108 工控机上面,在 Apollo 1.0 版本的官方文档就有介绍过 ESD CAN 型号是 ESD CAN-PCIe/402-1。它长这个样子：
在这里插入图片描述
ESD CAN 接收到的信号有 2 类：

线控底盘 CAN 信号
大陆毫米波雷达 CAN 信号

其实现叫做EsdMonitor，

在这里插入图片描述

它是RecurrentRunner的子类

在这里插入图片描述
EsdCanMonitor 在初始化时设置了自己的模块名和周期执行间隔，这里时间间隔是 3 秒，也就是 EsdCan 每 3 秒被监控 1 次。

在这里插入图片描述

我们也可以看到 EsdCanMonitor 的核心方法其实是 EsdCanTest。
在这里插入图片描述
在 EsdCanTest 中检测到的结果，最后会通过 SummaryMonitor.EscalateStatus 方法提升自身状态等级。

当然，如果 ESD CAN 根本不存在，那么就返回 ERROR 错误类型。

EsdCanTest 内部创建了 NT_HANDLE 类型变量 handle，并基于它进行测试。

在这里插入图片描述
应该是借助于EsdCan厂商自带的驱动测试函数。上面的代码很简单，通过调用３个函数进行了５类测试。

通过 canOpen 测试设备是否能够正常打开
通过 canStatu 测试设备能否正常获取状态
通过 canIoctl 测试是否能够获取CANBUS的分析数据
通过 canIoctl 测试是否能获取控制状态
通过 canIoctl 测试测试是否获取波特率

然后根据测试的结果返回。

测试的可能结果还挺多的,就不一一列出了。

NTCAN_SUCCESS:
     
NTCAN_RX_TIMEOUT:
     
NTCAN_TX_TIMEOUT:

NTCAN_TX_ERROR:
 
NTCAN_CONTR_OFF_BUS:
  
NTCAN_CONTR_BUSY:
  
...

然后 EsdCan 的监控的基本逻辑就没有了，它的工作更多借助于厂商的驱动测试API完成。

GpsMonitor

在这里插入图片描述
GpsMonitor 的代码更简单。

监控周期也是每隔 3 秒一次。

主要逻辑是接收GnssBestPose这个topic，获取它的状态，结果有三种：

如果是SolutionType::NARROW_INT，那么状态是OK
如果是SolutionType::SINGLE，那么状态是WARN
其他情况，状态被标志为 ERROR

GnssBestPose和SolutionType的定义都来自GNSS驱动，在gnss_best_pose.proto中

SocketCanMonitor

Socket CAN 是个什么东西呢？

我们知道 Socket，也知道在汽车行业中广泛通过 CAN 协议传输，那么 Socket CAN 是什么呢？

Socket CAN是Linux环境下基于socket机制实现CAN协议的一套机制。Apollo中也支持对它的监控。

在这里插入图片描述
它的核心代码是SocketCanTest

先通过socket获取一个操作句柄。注意socket的参数，PF_CAN 有别于我们常使用的 TCP 类 Socket 开发。

socket(AF_INET,SOCK_STREAM,0)

这说明SocketCan和普通的TCP/IP是不一样的。

SocketCanTest()中通过SocketCanHandlerTest执行操作，将操作结果放到message中

在这里插入图片描述
检测的逻辑也非常简单：

通过设置 filter，检测是否正常
通过尝试 enable CAN Frame 的接收检测是否正常
通过 bind socket 到网络接口检测是否正常

ResouceMonitor

ResourceMonitor监控的对象是那些通用的物理资源，当前包含CPU，内存，磁盘

在这里插入图片描述

在这里插入图片描述
ResourceMonitor每隔5s监控１次，它需要从HMI中获取受监控的配置项目。

CheckDiskSpace

在这里插入图片描述
在代码检测磁盘空间是通过 boost::filesystem 中的 space() 方法。

查询磁盘的总空间和剩余空间，可以使用boost::filesystem::space()
该函数返回boost::filesystem_space_info对象，有三个公有属性：capacity，free和available。这三个属性类型为boost::uintmax_t，以字节为单位。

得到的结果需要和 config 中规定的阈值进行判断，产生 ERROR 和 WARN 两种结果。

CheckCPUUsage

在这里插入图片描述
实际执行的是 GetSystemCPUUsage 或者 GetCPUUsage 方法。

核心逻辑无非就是通过代码执行命令行脚本 /proc/stat。这个命令包含了系统内核中很多信息，就如 CPU 信息。比如，我在我的 WIN11 系统中的 WSL 中查看 /proc/stat 信息，出现下面的结果：
在这里插入图片描述
cpu 状态有很多信息，每一列有独特的意义。

cpu 统计时间的单位是 jiffies。
大家可能在想，代码如何拿到 /proc/stat 信息的呢？

因为在 Linux 中，万物皆文件。只要通过 ifstream 读取那个路径，然后 getLine 一行一行解析就好了。
然后，如果要查看某个【进程】的占用的cpu 内存详细信息，则需要通过 /proc/pid/stat 命令。
在这里插入图片描述
有 4 种时间

utime 用户态时长
stime 内核时长
cutime 当前进程等待子进程的 utime
cstime 当前进程等待子进程的 stime

最终的 CPU 时长:

cputime = utime+stime+cutime+cstime

CPU 使用率公式：

usage = (time - pretime)/monitor_time

就是在一次监控周期内，两次 cputime 统计值的差占监控时间的比例。

CPU 状态是否报警取决于结果和配置中预设的值的比较。
在这里插入图片描述

CheckMemoryUsage

检查内存使用情况的逻辑和 CPU 差不多。
在这里插入图片描述
如果没有进程 DAG 则检测 SystemMemoryUsage 否则就通过 pid 一个个获取单个进程的内存信息。

通过命令行 /proc/meminfo 获取内存信息。

得到总共的内存，和当前使用的内存，然后求比例。
单个进程使用的内存信息通过 /proc/pid/statm 命令求得。
在这里插入图片描述
内存使用率公式：

 usage = usedMem/TotalMem

计算已使用了的内存在整个内存容量的占比。

CheckDiskLoads

字面意思是检测磁盘负载。
在这里插入图片描述
需要通过 GetSystemDiskload 获取各个设备的负载值，然后和配置中的阈值做比较，最终得到 Error 或者 WARN 状态。

借助的是 /proc/diskstats 命令,这个命令可以查看磁盘的相关信息。

第2列也就是 ram0、loop0、sda 之类是 devicename。
第12列是 I/O 耗费的时间，单位是 ms。

磁盘负债的比例计算公式是：

usage = (当前I/O时间 - 上一次I/O时间)/监控间隔时长

总结

Apollo 归类到硬件监控的内容不多，只有 4 个，ESD CAN、GPS、SocketCAN、Resource
监控本身的逻辑代码没有多少，更多借助于硬件本身的测试驱动方法，Monitor负责汇总
SocketCAN 的监控主要是在一个监控周期对它进行常规的 API 调用
System 健康问题被当成一个 Resource 对待
读取 /proc/stat 计算 cpu 使用率
读取 /proc/meminfo 计算磁盘使用率
读取 /proc/diskstats 计算磁盘负载
通过 Boost::FileSystem 的 space() 方法计算磁盘空间状态