1 系统的架构和功能

家庭智能控制系统主要由室内分机、单元门口机、小区围墙机、管理中心终端机、管理中心服务器以及附件组成。系统采用分布式网络结构，可以根据住户数量对系统的容量进行扩充。

（1）室内机是用户在室内进行操作的主要平台，其功能组成为：可视对讲、信息服务、家电控制、安防报警、家庭娱乐等。可视对讲模块主要实现双向可视通话、视频监控、留言/留影、开锁等功能；信息服务模块主要用来收发物业信息和小区广播，支持文本、图片形式，并实现与可视对讲模块的影音共享；家电控制模块包括对灯光、窗帘、空调、电梯等设施的无线控制，并预设了情境模式；安防报警模块支持对烟感、门磁、煤气泄漏检测等的自动报警，并可通过GPRS/3G技术将报警信息传送到用户手机上；家庭娱乐模块支持常见格式的音视频文件的播放（主要依靠硬件解码）以及对常见格式的图片的浏览（电子相框）。

（2）单元门口机的主要功能是完成与所在单元楼的任意住户以及管理中心机的可视通话，除了具备留言/留影功能外，还提供触摸屏校准、背光调节、密码设置等功能。

（3）围墙机的基本功能和单元门口机类似，但可视对讲、留言/留影功能是针对小区内所有住户的。

（4）中心机是整个系统的神经中枢，管理人员通过管理中心的控制设备管理各子系统的终端，其功能包括：可视对讲、视频监控、查看报警信息、排除设备故障、信息服务、系统设置、远程管理等。

2 系统的实现方案

2.1 Qt的信号/槽机制

Qt是一个跨平台的C++应用程序框架，完全面向对象、易于扩展且允许真正的组件编程。Qt的C++类库封装了适应不同操作系统的访问细节，这使得它能够快速地部署于各种桌面与嵌入式系统中［1］。

信号/槽机制是 Qt 的核心特性，这种机制真正实现了消息的封装，完全可以取代原始的回调和消息机制。信号和槽的连接通过connect（）函数完成，connect（）函数是QObject类中的静态函数，其函数原型如下：

Bool QObject：：connect（const QObject* sender，

const char*signal，const QObject* receiver，const char* member）

其中，sender和receiver是指向QObject的指针，signal和slot是不带有参数的函数名。

2.2 基于XML格式的Socket多线程通信

Linux中的网络编程主要通过Socket接口实现，在Qt环境里，对Socket进行了封装，并建立了相应的QTcpSocket类来实现TCP客户端和服务器的通信。QTcpSocket继承了QIODevice，所以QTcpSocket可以使用QDataStream进行数据的读取和写入。

可扩展标记语言XML（eXtensible Markup Language）是一种用于数据交换和数据存储的多用途文本格式。对于XML格式的数据，Qt中的QtXml模块提供了DOM和SAX两种处理方式。本文采用的DOM方式把XML文档转换成一个可以遍历的树形结构，这样便可以随意访问其中的节点，因此要明显简洁得多。

室内机和中心机之间的通信采用多线程方式实现。多线程方式具有降低内存、提高程序响应速度等优点，特别适用于嵌入系统。系统中建立了三个主线程：（1）GUI线程：用于执行main（）主函数，响应用户的界面操作；（2）tcpServer侦听线程：用于对指定端口进行监听；（3）tcpSocket传输线程：负责消息的接收和回复。下面以用户主动更新小区广播为例详细说明Socket通信的流程：（1）室内机首先启动一个线程，将用户的更新请求结构转化成标准的XML格式（如果是新设备第一次开机，要先手动进行IP的设置），（2）调用connectToHost（）函数请求与中心机建立连接，处于监听状态的中心机接到请求后，就会分配一个Socket套接字来处理连接：首先根据解析出来的XML的Type节点判断请求类型，如果是纯文本则从数据库的Text表读取，如果是图片则从硬盘读取，然后调用QIODevice：：write（）函数发送；（3）室内机接到应答信号readyRead（）后就开始进行信息的收取，根据消息的Type节点类型分别写入数据库和硬盘。Socket多线程通信流程如图1所示。

2.3 并行数据库设计

为了实现数据库的并行操作，使GUI界面与数据库相分离，从而让界面能更快地响应用户的一般操作，同样要用到Qt的多线程编程。在系统启动时，首先要建立一个全局对象m_query，以便于各个实体类与数据库类进行连接。这样，每当有数据库操作请求时便会实例化一个m_query来创建一个线程用于处理该请求。m_query对象中包含两个类：（1）QueryThread，用于为每个数据操作创建一个线程；（2）Worker，用于实现数据库的相关操作，如加载数据库驱动、进行数据查询/插入/删除等。

图2为数据库的查询操作流程。首先在实体类里创建两个connect连接，分别用于发送和接收查询结果，并生成SQL语句向QueryThread提交查询请求信号。QueryThread收到请求后为其创建一个线程，并交由Worker类进行具体数据库查询操作。Worker类得出查询结果后，先传递给QueryThread，再由其将查询结果返回到实体类。

关键代码如下：

connect（ this，SIGNAL（seek（const QString& ） ），m_query，

SIGNAL（seek_execute（const QString& ）） ）;

connect（ m_query，SIGNAL（seek（const QList <QSqlRecord>

& ） ），this，SLOT（ slotResult（ const QList <QSqlRecord> & ） ） ）;

…

void text：： database（） {

QString sql = “select * from Text order by date desc ”;

emit seek_execute （sql）;

}

2.4 音视频同步传输技术

i.MX51处理器包含了支持硬件视频编解码的VPU单元，并自带了完整的多媒体解决方案。因此，系统中采用其自带的多媒体软件包进行音视频流的采集和编解码［2］。

考虑到小区内可视通话时因并发数过大而可能导致的网络拥塞情况，系统还需要提供一定的QoS机制来保证在网络带宽较低时也能达到音视频的同步传输。本文采用基于时间戳的实时同步传输技术，通过设置可变大小的缓冲区机制，根据小区网络情况自动调节传输参数，以音频质量优先保证为原则，根据时间戳实时调节视频数据的播放。具体实现过程如下［3］：

（1）发送端采用两个独立的进程分别对音视频信息进行采样和打包，然后放到各自的缓冲队列中等待发送。

（2）音视频数据通过同一个通道发送到网络（采用信号量机制保证音视频数据对通道的互斥访问）。

（3）由于音视频两个数据包的长度差别很大，所以将接收端收到的数据根据包的大小进行区分。

（4）音视频各自拆包组帧。由于人的听觉对声音的不连续比视觉对图像的不连续更敏感，所以采用音频流作为主流，视频流作为从流。客户端接收到音频数据包后，不必与视频数据包协调就可立即播放，而视频帧到达时则根据时间戳进行对比，从而进行相应的同步处理。

（5）为保证音视频的实时同步，采用多线程分别对音频和视频进行播放。

3 i.MX51平台移植

3.1 搭建LTIB开发环境

ltib（Linux Target Image Builder）是飞思卡尔公司开发的一个用于部署BSP的工具，含有U-Boot等引导加载程序，支持Bootloader和内核映像的构建。利用该工具，可以定制出符合GNU/Linux标准的跨平台的根文件系统。本设计选择使用飞思卡尔公司提供的L2.6.31_10.07.11_ER_source.tar.gz集成源码包，在一台安装了Ubuntu 10.04操作系统的PC机上配置安装LTIB［4］。其过程如下：

（1）解压缩源码包，执行。/install进入安装LTIB的命令提示。

（2）执行。/ltib进入LTIB的配置界面。

（3）在LTIB配置Platform时选择i.MX51平台。

（4）配置Kernel时选择CLAA WVGA Panel（LCD触摸屏驱动）和SoC Audio support for IMX - SGTL5000（声卡驱动），其他保持默认。

（5）将交叉编译工具arm-none-linux-gnueabi-gcc加入PATH环境变量，在ltib根目录执行下述命令，交叉编译Qt库：

./ltib -m prep -p qt-embedded.spec

./ltib -m scbuild -p qt-embedded.spec

（6）执行make install，在ltib下的rootfs目录就会生成相应的U-Boot、内核和文件系统，将将其复制到目标板的TF卡上。

3.2 架设NFS文件系统

为了简化调试过程和缩短开发周期，在Linux主机上建立了NFS网络文件系统，这样就实现了宿主机与目标板的文件共享。开发过程简化为：Linux主机编译生成目标平台的可执行文件→复制文件到NFS共享目录→目标板运行程序，从而省去了重复制作镜像、下载镜像、重启开发板等步骤，节省了大量的开发时间。目标板的NFS启动信息如图3所示。

4 系统测试及结果

4.1 并发测试

并发测试主要用来测试多个用户同时访问同一个应用程序、同一个数据记录时是否存在死锁或其他问题。由于本系统是面向一个小区的住户，因此系统的并发测试尤为重要。

数据库并发测试：室内机开启多个线程同时访问中心机服务器，界面并不会因大量的数据操作而出现“冻结”现象，CPU占用稳定，数据库返回结果显示正常。

信息发布测试：中心机开启多个线程同时发送广播信息，各室内机接收正常，不会出现显示错误或“丢包”现象。

4.2 跨网段测试

考虑到小区用户一般在几百甚至上千，一个网段的IP地址不能满足需求。为了检测在不同网段下通信模块能否正常工作，使用一台华为S5300交换机（switch）和两台华为5200交换机搭建了一个小型的网络环境进行相关测试。如图4所示，测试采用IPv4静态路由，使不同网段的任意两台室内机之间能够互通。测试表明，分属不同网段的室内机之间，可视通话、信息互发等模块均正常工作，从而验证了本设计方案的可行性。

4.3 可视对讲性能测试

可视对讲性能测试主要是检测室内机终端中音视频的采集、编解码、收发和显示。对于音视频的采集、收发和显示，可通过扬声器和LCD显示直观地检测。而对编解码的测试则比较复杂，本设计是从最长时间、最短时间和平均时间三个方面来测试编解码一帧音视频所需要消耗的时间。i.MX51平台上音视频编解码的性能测试如表1所示。

由表1可以看出，i.MX51平台上能够实时地完成音频和视频通信，且音频清晰、视频流畅、失真度小，达到了可视对讲对音视频编解码器的实时性要求。

本文采用Linux和Qt相关技术，在飞思卡尔公司i.MX51平台上设计了一种多功能的智能家居控制系统，实现了客户端与服务器的Socke通信和音视频同步传输等核心功能。下一步还需要扩展家电控制、安防控制等功能。