【《基于CAN数据采集系统的乘用车智能故障诊断盒设计》10000字】

基于CAN数据采集系统的乘用车通用智能故障诊断盒设计摘要：如今汽车已非常智能化，汽车中有着众多的传感器与ECU，汽车故障的诊断已不再完全依靠认为的感知以及经验，设计一款智能诊断盒有益于对汽车的工作状况进行监督。本文主要从硬件与软件两个方面对故障诊断盒进行设计。该诊断盒通过CAN数据采集系统，采集汽车ECU中存储的信息，并通过解析，当有故障时，将故障信息发送给报警器，显示器，显示器通过处理显示故障代码，相关使用人员通过查询数据库得到车辆状态、故障码等信息，并解析故障点和故障原因。关键技术主要是CAN总线技术，汽车电器与电子技术、微机原理等。根据综合综合实验的需要进行电源模块、MC9S12XS128主控模块、CAN总线通讯模块、报警蜂鸣器模块、显示屏模块和按键模块的设计，通过C语言的代码的编写，进行车辆数据的采集与对采集信号的数据解析。在硬件方面，基于飞思卡尔单片机等芯片、CAN总线通讯与报警蜂鸣器等硬件电路及实物。使用AltiumDesigner完成电路图的设计工作，在软件方面，用CodeWarrior软件对相关代码进行编写,同时对CAN总线通讯模块、报警蜂鸣器模块进行测试。关键词：乘用车、通用、智能、诊断目录TOC\o"1-3"\h\u1372第1章绪论 1168151.1课题研究背景及意义 190251.2国外内现状 1273551.3目前存在主要问题 2325931.4本文主要研究内容 212176第2章设计方案及相关技术 2286632.1设计总体要求分析 238342.2系统总体方案设计 3300152.3OBD-Ⅱ简介 3181982.3.1OBD-Ⅱ通讯协议 4134522.3.2OBD-Ⅱ工作原理及及接口 4123972.3.3OBD-Ⅱ模式介绍 5267362.3.4OBD-Ⅱ通用故障码 551572.4主要诊断参数 625354第3章硬件设计 6214553.1电源模块 7315943.2MC9S12XS128主控模块 8216123.3CAN总线模块 10161253.4报警蜂鸣器模块 11287263.512864液晶接口模块492 12138573.6按键模块 1231420第4章软件设计 12125324.1型号为TJA1050的CAN的软件驱动 12167764.1.1CAN程序初始化 1241624.1.2CAN的接收与发送 1340874.2读取信息 15145834.2.1读取车辆信息 16145834.2.2诊断故障码的获取 1645634.3故障信息数据解析 17306714.4蜂鸣器与显示屏 186454.4.1蜂鸣器报警 18172664.4.2显示屏显示故障码 19284764.5按键 2050第5章实验测试 2189245.1开发板硬件实体 21184345.2信息获取测试 2123432第6章结论 2289246.1本文结论 2289246.2未来展望 2210973参考文献 23第1章绪论1.1课题研究背景及意义这几年来，国家的发展越来越好，各家的收入水平提高，每个人不仅追求物质上的享受，同时还追求精神上的享受，因此许多家庭为了旅游等出行方便，都购买了私家车，汽车的需求量也不断增加，经过问卷调查，许多家庭不止拥有一辆机动车，而由此也带来许多问题，例如空气污染，交通事故等。空气中的CO、CO2、HC、NOX等有害气体大都来自汽车的尾气得排放。同时随着汽车的增多，由汽车故障所引起的交通事故也随之增多，为了解决这一问题，本课题合理的设计了一款智能诊断盒，该诊断盒通过连接汽车中的ECU获得车辆的故障数据以及行车信息，可以实时的检测到汽车的故障所在，同时还能检测到尾气的排放指数，从而判断该车辆的排放是否符合国家的标准，这不仅减少的尾气排放还减少了每年由于车辆在高速上突发故障而造成的危害。1.2国外内现状智能诊断盒主要是OBD系统，OBD系统能够实时的检测到车辆的故障以及尾气排放问题，该系统结构比较复杂，它检测车辆的功能能够实现主要是由硬件电路和软件代码共同实现的。美国的OBD系统共经历了两个阶段，分别是OBD-Ⅰ、OBD-Ⅱ。起初OBD-Ⅰ被研究出，但经过一系列的实验，发现有很多不足的地方，而且能够测量到的数据很少，因此在此基础上又研发了OBD-Ⅱ，OBD-Ⅱ相对于OBD-Ⅰ来说测量的数据更加全面，但是这两个阶段的系统都有各自的特点。OBD-Ⅰ最早起源于八十年代的美国，此时的系统主要能够诊断车辆的个别硬件系统，但同时它有些缺陷，如标准不统一，每辆车都有不能的标准与解码器，而且该系统非常昂贵，同时它所检测到的故障信息很有限，不能及时诊断出故障，为了弥补OBD-Ⅰ的缺陷，美国公司又研发了OBD-Ⅱ，相对于OBD-Ⅰ系统来说，OBD-Ⅱ系统规范统一的标准，扩大了检测数据，提高了争端的质量，能够及时检测出故障问题，大大减少了经济的损失。从2000年开始，欧共体要求欧洲各国汽车制造商生产的轿车都相应配置欧洲电控汽车故障诊断系统，及EOBD。2001年欧洲所有新生产的轿车都要配置EOBD系统，而对于柴油发动机轿车要求在2004年强制配置EOBD系统。[1]我国对该项技术的研发较晚，但是发展趋势很迅猛。在90年代底，就开始涉猎OBD相关技术的研究了，许多科研机构分分研发OBD系统，并取得了一定的成果。随着我国Ⅲ排放标准在全国范围内的逐步实施，OBD技术的研究已经全面展开，包括低排放车辆OBD检测原理，欧洲法规对OBD系统的技术要求，OBD功能性演示试验失效零部件或模拟器的研制，OBD试验认证程序制订和OBD与在用车排放管理、排放缺陷召回等制度方面的相关研究。如今OBD技术已经很成熟，从原始的OBD诊断盒到云客户端诊断，这一系列的发展，大大减少了行车的故障问题。[1]1.3目前存在主要问题市场上OBD诊断盒价格昂贵，相对体积过大，普通拥有车辆的人很少会单独购买该终端。个别诊断盒读取的故障数据较少。个别诊断盒所用到的芯片的功能有缺陷，在测量时并不能及时显示故障结果，反应迟钝。1.4本文主要研究内容本课题主要任务是根据综合实验的需要进行通信模块、显示模块、报警模块设计，并完成相应程序设计同时完成对采集信号的数据解析，一种基于OBD-Ⅱ诊断盒的车辆故障诊断系统，实时获取车辆的识别的信息，故障码等数据，并进行报警处理，实现故障诊断功能。第2章设计方案及相关技术该章节主要从系统的总体设计方案和方案中涉及的关键技术两个方面做出了详细的介绍。该系统主要是能够通过连接汽车中的ECU，及时完成故障数据以及行车信息的采集、报警以及显示故障码功能。因此，解决方案的设计必须考虑如何实现各个部分的工作。具体所涉及的技术如下：OBD-Ⅱ技术、报警技术和显示技术。2.1设计总体要求分析汽车故障诊断系统的主要功能是在及时获取汽车ECU系统中的故障信息和行车数据等，从而使使用者能够及时的掌握好自己所拥有车辆的信息，及时将车辆送往汽车保养公司，对汽车进行全面性的检查，这大大减少了由于突发故障而造成的人身安全以及交通堵塞问题。通过设计前的实习过程中，大致了解了诊断系统诊断过程以及它所必备的一系列共功能：及时取得车辆ECU的故障以及行车数据首先，系统需要与汽车中的ECU系统获取联系，用连接线一端连接ECU一端连接OBD系统；OBD系统大概由三种通讯协议，每个生产厂家会有他们自己相应的通讯协议，所以不同类型的车辆对应不同通讯协议，因此为了获得车辆ECU的信息，该系统必须支持不同类型的车辆；因为，车辆ECU中包含大量的车辆信息数据，而本次所设计的系统只需要获取ECU中的基本故障信息并对其进行解析报警显示等。因此，需要运用CodeWarrior软件对所设计的每个模块进行编程和调试处理，从而获得所需要的数据信息。正确分析和处理车辆信息当该系统及时获取车辆ECU中的大量故障信息时，就要对对应的CAN系统编程，对提取到的信息，如故障代码等，进行分析处理，及时发送到报警系统以及显示系统中。故障报警通过对蜂鸣器进行编程，使系统发现车辆发生故障时，及时进行报警，提醒使用者该车辆有故障发生，及时送往保险维修公司进行维修。显示故障码显示屏LED显示故障码，用户通过查询通用故障码，初步了解故障原因，大致对车辆进行自我维修。2.2系统总体方案设计根据上面的要求分析，对总体方案做了粗略的设计，该系统主要由故障检测终端组成。只能故障诊断盒的OBD接口通过连接线与汽车中的ECU相连接，MC9S12XS128主控芯片定时的将获取信息的指令送给TJA1050车辆数据采集模块，及时采集车辆ECU的数据流，在完成数据采集之后，发现故障时蜂鸣器进行报警处理，显示屏LED显示故障代码，根据国际标准的故障码，确定故障原因，具体框架图如图1所示。图1检测时的框架图2.3OBD-Ⅱ简介20世纪80年代，许多发达国家的汽车制造商就广泛使用电动发动机。第一代车载诊断系统集成在电控喷气发动机控制系统中。随后，车载故障诊断系统逐渐应用于微机控制的自动变速器、防抱死制动系统、安全气囊和巡航系统。该系统可在电子控制装置运行过程中随时控制系统各部分的运行状态，当电子控制系统出现故障时,故障有关的资料都储存在微电脑中，车辆的维修人员的连接端子的开关接头，同时按规定的方法来分析和诊断整车电子控制系统的故障。OBD系统是一种可扩展的机动车故障诊断和检测系统。起初由于汽车尾气的大量排放而造成的污染，为了控制尾气的排放指标以及排放量，从而起到保护环境的作用，才设计了OBD系统。OBD技术目前已经发展的很成熟，被广泛应用于机动车故障诊断的过程中。OBD系统通过CAN模块获取存储在ECU中的故障信息及行驶数据库，车辆维修人员通过查找通用故障码，以确定故障的原因和位置。2.3.1OBD-Ⅱ通讯协议 不同的车辆制造商有不同的通讯协议，因此，每个厂商所设计的每个种类的车都有他们相应的通讯协议。OBD-Ⅱ标准使用的通讯协议一般有：ISO9141-2、ISO14230-4（KWP2000）、SAEJ1850PWM、SAEJ1850VPM、ISO15765-4（CAN-BUS）。ISO9141-2总线的协议IS09141-2协议是汽车行业最常用的通信协议之一，属于标准OBD-Ⅱ协议的一种，它的物理层空闲电平通常为12V，数据帧有两种分别为命令帧和响应帧。（2）ISO14230总线的协议在汽车故障领域，各汽车公司都制定了诊断设备与汽车ECU之间数据交换的相关标准和协议。其中，在欧洲汽车领域广泛使用的车载诊断协议标准KWP2000实现了一整套车载诊断服务，符合E-OBD标准。KWP2000最初是基于K线的诊断协议。由于K线物理层和数据链路层在网络管理和通信速率方面的限制，k线不能满足日益复杂的车载诊断网络需求。CAN网络以其非破坏性的网络仲裁机制、高通信速率和灵活可靠的通信方式，在车辆网络领域受到广泛青睐。越来越多的汽车厂商将CAN总线应用于汽车的控制、诊断和通信。近年来，基于CAN总线的KWP2000即ISO15765协议在欧洲汽车领域得到了广泛应用，而基于K线的KWP2000物理层和数据链路层协议将逐步淘汰。（3）ISO15765总线的协议基于CAN总线的KWP2000协议实际引用ISO/WD15765-1～15765-4。该协议将KWP2000应用层的诊断服务传输到CAN总线。数据链路层采用ISO11898-1协议，是对CAN2.0B协议的进一步标准化和规范化。应用层采用ISO15765-3协议，完全兼容基于K线的应用层协议14230-3，并加入CAN总线诊断功能组；网络层使用ISO15765-2协议,它定义了网络层协议数据单元之间的映射关系,数据帧,底部和上部KWP2000服务,并提供同步控制、顺序控制、流控制和错误恢复功能的多包长消息的数据传输过程。2.3.2OBD-Ⅱ工作原理及及接口OBD-Ⅱ系统对ECU接口和外部设备连接的统一规定，OBD跳线盒原理具体如图2所示。图2OBD跳线盒原理汽车OBD诊断座的位置并不是很确定，每个生产厂家有不同的设计，大概有4个位置，如位于方向盘左下角，位于方向盘右下脚，位于中控台下方点火器附近，位于中央扶手箱里，但是最常见的位置位于方向盘左下角，有16针孔，不好测量，OBD诊断盒设置16个检测孔。分别测试每一根线，4为车身搭铁，5为信号搭铁，16为蓄电池正极，其余引脚由家自行设定。具体如图3所示。图3OBD诊断接口图2.3.3OBD-Ⅱ模式介绍通过OBD-Ⅱ模式我们可以去请求车辆上动力系统的一些数据，但是这些数据都是需要预先定义好的，ISO标准规定了一些参数表示即PID，每一份PID代表一个变量参数，目前OBD-Ⅱ共有9种服务模式，具体如表4服务功能01请求动力系统当前数据（速度、里程、温度等）02请求冻结帧数据03请求排放相关的故障码04请求排放相关故障信息05请求氧传感器的检测结果06请求指定监控系统的测试结果07请求当前或上一驱动周期检测到的排放相关的故障码08请求控制在线系统或组件09请求整车信息表4OBD-Ⅱ服务状况2.3.4OBD-Ⅱ通用故障码 要对CAN系统进行编程，从而处理从ECU系统中获得的故障信息，最终在显示屏显示故障代码，故障代码一般五位数组成，第一位为字母，分别为P、B、C、U，P为动力总成系统，B为车身系统，C为底盘悬挂系统，U为网络通讯系统；第二、三、四、五位位数字；第二位的数字一般有0、1、2、3；0为通用故障码，1为制造商自定义故障码，2为通用故障码，故障码详细解析如图5图5故障码详细解析ISO标准规定了一些参数标识即PID，每一个PID代表一个变量参数，表6列举了01模式下个别的PID参数，如下所示。PID长度字节描述数据类型014故障码清除之后的检测状态\041引擎负载\051发动机冷却液温度\0C2发动机转速Data/4rpm（0＜data＜1638375）0D1车速Datakm/h（0＜data＜255）1F2启动后运行的时间\表601模式下PID参数2.4主要诊断参数OBD诊断盒的设计主要是为了监控尾气排放，在一定的标准下，可以排放到大自然，而本次设计主要是诊断车辆发生的故障，从而减少交通事故的发生。能够测量的参数：发动机转速、发动机温度、发动机负荷、燃油压力、点火正时角度、角度节气门开度、歧管真空度、油轨压力、进气管压力、进气温度、空气流量、电瓶电压、冷却液压温度、蒸发系统压力、长时燃油修正百分比、时燃油修正百分比、EGR开度、蒸发冲洗控制百分比等。第3章硬件设计智能诊断盒的硬件设计主要包括电源模块，MC9S12XS128主控模块、型号为TJA1050的CAN收发信息模块、报警蜂鸣器模块、显示屏LED模块，具体结构如下图7所示图7硬件总体设计故障诊断盒与车辆的OBD接口相连接，从汽车蓄电池中获取电量，供应诊断盒各个模块工作，车辆蓄电池的额定电压为12V～24 V左右，而所设计的故障诊断盒各个模块能够通过的最大电压并不能达到这种电伏，所以获取的电压要经过硬件的电源模块进行降压处理，然后分别供给型号为TJA1050的CAN收发信号模块、MC9S12X128主控模块、报警蜂鸣器模块和显示屏模块使用，型号为JTA1050的CAN收发信号模块通过编写正确代码与车辆ECU建立联系，从车辆中获取正确的故障和行车信息，报警蜂鸣器负责收到故障时发出报警警告使用人员，显示屏显示故障代码，MC9S12XS128主控模块负责控制JTA1050收发信号模块采集车辆信息，进行数据的处理以及提醒报警蜂鸣器模块发出警报。3.1电源模块车辆蓄电池的额定电压为12V～24 V左右，但是MC9S12XS128单片机和蜂鸣器报警器的工作电压为5V,JTA1050的工作电压为5V,所以为了满足各个模块的不同供电要求，就要对获取来的电压进行降压处理。该电源模块要将获取来的电压进行降压处理，因此设计时就要开关后设计一个750mA的保险丝。C11、C12、C13分别是100μF/25V、0.1μF和220μF/16V的电容,对电路起到稳定电压和过滤杂波的作用，具体电路如图8所示。图8电源降压模块3.2MC9S12XS128主控模块MC9S12XS128单片机是一款比较特别的单片机系列，它的内核是以速度更快的CUP12为核心，它是MC9S12X系列的单片机，16位微控制器112pin，16MHZ晶振，内部总线频率可超频至64MHZ-96MHZ，有4位LED指示灯，CPU12是16位高速处理单元,内部有5个16位寄存器和一个8位的状态寄存器，内部再用全16为数据总线，外部数据总线8位/16位可选，包括CPU寄存器、CPU控制电路和ALU算数/逻辑运算等操作，用途十分广泛其主要功能如下：存储器：128KBFLASH；2KBEEPROM；8KBRAM增强型捕捉定时器；CAN总线：3个1Mbps的CAN总线，兼容CAN2.0A/B;背景调试模式（BDM）；MC9S12XS128主控模块的PK4引脚向外连接一个电阻为1K的电阻器，来控制LED灯。低电平时LED灯点亮。JA1为BDM调试接口，KA1为复位按键，具体电路如图9所示，个别引脚功能如表10所示。图9MC9S12XS128主控模块表10是MC9S12XS128个别引脚功能说明引脚号功能功能说明功能1功能2功能3功能4功能51PP3KWP3PWM3端口P：通用1/O，中断，PWM通道2PP2KWP2PWM2IOC1TXD1端口P：通用1/O，中断，PWM/TIM通道，SCI1的TXD3PP1KWP1PWM1IOC1端口P：通用1/O，中断，PWM/TIM通道4PP0KWP0PWM0IOC0RXD1端口P：通用1/O，中断，PWM/TIM通道，SCI1的RXD9PT0IOC0端口T：通用I/O，TIM通道10PT1IOC111PT2I0C212PT3IOC315PT4IOC4PWM4端口T：通用I/O，PWM/TIM通道17PT6IOC6PWM618PT7IOC7PWM716PT5IOC5PWM5VREGAPI端口T：通用I/O，PWM/TIM通道，API输出24PB0端口B：通用I/O29PB530PB631PB757PA0端口A：通用I/O58PA159PA260PA33.3CAN总线模块该诊断盒CAN总线模块选用TJA1050的芯片，该芯片与芯片内的CAN模块相连来实现CAN通信的功能，芯片使用的是5V的电源供电，因此需要电源模块对收到的电压进行降压处理，TJA1050收发器的引脚1号与4号分别与MC9S12XS128主控模块的PM1与PM0相连；引脚2号和引脚8号接地；引脚3号与电源线连接；引脚7号与引脚6号分别于CANH和CANL相连接。具体电路如图11所示。图11CAN总线模块3.4报警蜂鸣器模块报警蜂鸣器模块的功能主要是在得知有故障发生是进行警报提醒，硬件主要运用到了型号为8050的三极管，当有故障发生时，它的输入端BUZZ为1，这是电路接通，电压经过三极管通向蜂鸣器，BUZZER开始报警；当故障数目为1时，即输入端BUZZ为0，此时电压无法经过三极管，只能通向地面。蜂鸣器不发生声响，具体电路如图12所示。图12报警蜂鸣器模块3.512864液晶接口模块该设计的诊断盒要实时的显示故障个数与故障码，因此硬件部分要选用12864液晶接口，外接一个显示屏。该模块有20个引脚，其中引脚3外接两个分别为1K和10K的电阻，一端接地另一端接电源，这两个电阻主要起到分压的作用；引脚17外接一个10K的电阻并与电源相连，这里电阻的作用是保护电路。具体电路如图13所示。图1312864液晶接口模块3.6按键模块设计一个按键模块，并连接一个10K的电阻，并联一个0.1μF的电容，同时与最小模块中的第27个引脚PH3连接，该按键的主要功能是控制信号的发送，即当按键按下时，CAN模块开始接收汽车ECU中的信号并解析故障个数与故障码。具体电路如图14所示。图14按键模块第4章软件设计4.1型号为TJA1050的CAN的软件驱动CAN总线主要功能是接收信号和发送信号，同时能够有效的采集信号，应用的领域很广，而本次设计的诊断盒是以型号为TJA1050的CAN总线，主要包括CAN程序初始化和CAN的接收与发送。4.1.1CAN程序初始化CAN的初始化主要包括五个部分，分别为：CAN的初始化、CAN波特率的设置、关闭波特率、使CAN模块进入一般模式、设置能够使接收中断，具体步骤如下：第一步：查询是否进入初始化状态，如果不是，及设置CAN0CTL0_INITRQ为1,CAN0CTL1_INITAK为0，使CAN进入初始化。第二步：设置CAN的波特率。首先设置同步，即CAN0BTR0_SJW为0，然后设置波特率，即CAN0BTR0_BRP为7，设置时段1和时段2的Tq个数，总线频率为250KB/s，即CAN0BTR1为0x1c。第三步：关闭滤波器。将一系列的CAN0IDMR0、CAN0IDMR1、CAN0IDMR2、CAN0IDMR3、CAN0IDMR4、CAN0IDMR5、CAN0IDMR6、CAN0IDMR7都设置为0xFF。第四步：使MSCAN模块进入一般模式，选择时钟，即将CAN0CTL1设置为0xC0，其次返回一般模式运行，即CAN0CTL0为0x00，最后等待回到一般运行模式并等待总线时钟同步。第五步：设置能够使接收中断，即CAN0RIER_RXFIE为1。具体流程如图15所示。图15CAN初始化4.1.2CAN的接收与发送MSCCAN在接受信号时，首先要检测接受标志，这里就要设置CAN0RFLG_PXF寄存器，接着要检测CAN协议报文模式，设置CAN0RXIDR1_IDE寄存器来加测标识符，随后要读标识符，这里要用到CAN0RXIDR0和CAN0PXIDR1两个寄存器，其次要判断帧的格式，然后读取数据长度，通过读取CAN0RXIDLR寄存器获取数据长度，接着就是要读取数据，通过查询CAN0RXDSR0寄存器来读取数据。最后清除RXF标志位，缓冲器准备接收，即设置CAN0RFLG为0x01。具体接收流程图如图16所示。图16CAN接收信号流程图MSCCAN在发送信号时，首先要检查数据长度如果数据长度超过8个，CAN就不发送该数据，接着要检查总线时钟，使用外部晶振时钟，设置CAN0CTL0_SYNCH寄存器为0，随后要寻找空闲缓冲器，其次要写入标识符，此处要用到CANIDR寄存器，然后判断帧类型，即判断是远程帧还是数据帧，接着就是要写入数据以、数据长度和优先级，分别用到了CANDSR、CANDLR和CANTBPR三种寄存器。最后，清除发送标志，即设置CAN0TFLG为send_buf。具体发送流程图如图17所示。图17CAN发送信号流程4.2读取信息通过与车辆ECU建立联系，读取一系列的车辆信息以及故障码信息，并对这些信息进行解析，通过查表，最终得知故障原因。4.2.1读取车辆信息每次发动机启动时，ECU都必须开始一系列的诊断检测，OBD系统通过09服务器下的三项数据来获取信息，并分析发送数据置报警器和显示屏中，这三项数据主要是车辆识别、校标准识别、校准检定码，读取车辆信息具体流程图如图18所示。图18读取车辆信息4.2.2诊断故障码的获取OBD系统通过连接线获取车辆ECU中的故障信息，判断个帐吗数量，并解析每个故障，最终发送给蜂鸣器和显示屏。首先，诊断盒要发送指令给服务器01中的 PID$01,获取DTC指示情况并解析，判断故障码数量，若为0时，即系统正常，若不为0时，及说明系统有故障发生，这时就要发送03模式指令获取故障码详细信息，并解析故障码总数以及每个故障号码，最后将故障发送至报警器和显示屏中，报警器收到故障时发生报警，显示屏显示故障码，便于查询故障原因。具体流程图如图19所示。图19诊断故障码获取流程图4.3故障信息数据解析OBD-Ⅱ的ISO15765-2网络层协议，一次性只能发送长度为8的报文，而车载信息报文不止8个，所以要分为单帧和多帧传输方式，硬件设备与车辆ECU建立联系后，首先车辆要发送连接成功的信号给硬件系统，然后硬件系统要发送0101给车辆来判断是否存在故障，当收到的数据帧中第4个字节为00是，即无故障发生，当数据帧中第4个字节不为00时，则说明有故障发生，并能够判断出故障的个数，此时硬件系统要将收到的信息反馈给车辆，这是车辆将具体的数据帧发送给硬件系统。假设收到的数据帧为0641018268264600，这组数据帧中的0x06表示它有效的数据长度为6，0x41与表示对0x01的成功响应，0x01表示有1个故障发生，如假设收到的数据帧为0643020703164100，则0x06表示它的有效长度为6个，0x43表示对0x03的成功响应，0x02表示有2个故障发生，0x07与0x03则表示第一个故障码信息，0x16与0x41则表示第二个故障码信息。0x07与0x03转化为二进制分别为00000111与00000011，通过查表18～20可知具体的故障码为P0703,将0x16和0x14转化为二进制分别为00010000和00001110，通过查表20～22可知具体故障码为P1641。表20五位标准故障码故障内码DTCHighByte（Hex）DTCMiddleByte（Hex）Bit15Bit14Bit13Bit12Bit11Bit10Bit9Bit8Bit7Bit6Bit5Bit4Bit3Bit2Bit1Bit0五位标准故障码第一位第二位第三位第四、五位表21第一位字母所表示故障所示系统故障内码（Bit15Bit14）标准故障码的表示字符1所属系统00P动力系统故障01C底盘故障10B车身故障11U网络故障表22第二位数字表示故障类型故障内码（Bit13Bit12）标准故障码的表示字符2故障类型000ISO/SAE标准定义的故障码011制造商自定义的故障码102ISO/SAE预留113ISO/SAE预留4.4蜂鸣器与显示屏经过一系列的信号接收、发送以及解析等步骤，为了具体了解故障原因以及及时提醒该车辆已经发生故障，因此要对蜂鸣器以及显示屏硬件模块进行程序编写，当检测到故障时，蜂鸣器能够报警以及显示屏能够显示出故障个数和具体的故障码。4.4.1蜂鸣器报警首先将蜂鸣器初始化，将BUZZ_dir设置为1，LEDCPU_dir设置为1，然后设置计时中断函数，即当检测到故障时，蜂鸣器每相隔5s响一次。主要流程图如图23所示。图23蜂鸣器报警流程图4.4.2显示屏显示故障码首先将液晶接口初始化，即PSB_dir=1，SCL_dir=1，SDA_dir=1，CS_dir=1，PSB=0，SCL=0，SDA=0，CS=0；然后向液晶发送数据，即CS=1，SCL=0，write_byte（0xFA），write_byte（C&0xF0），write_byte（0xF0&（C<<4））,CS=0；其次是向液晶发送命令，即CS=1，SCL=0，write_byte（0xF8），write_byte（B&0xF0），write_byte（0xF0&（B<<4））,CS=0，接着在液晶上显示接收到的数据，即unsignedcharl，write_command（0x8A），for（l=0，l<msg_get，len，i++），write_Data（msg_get，data[1]）,最后清屏。具体流程图如图24所示。图24显示屏显示流程图4.5按键此处按键的作用主要是按下按键时，CAN模块开始接收发送处理ECU的信息。首先要初始化按键，即KEY1_dir=0，PPSH=0x00，PIFH=0x0f，PIEH=0x0f,然后要设置按键中断函数，即要判断中断标志，然后要清除中断标志,最终在主函数中调用。具体流程图如图25所示。图25按键流程图实验测试5.1开发板硬件实体硬件板块如图27所示，其中主要运用到最小单元芯片，CAN模块，显示屏，蜂鸣器，按键等模块。图26硬件图5.2信息获取测试将所编写的代码导入设计的硬件板块中，能够准确获取故障码，同时当检测到故障时，蜂鸣器能够实现报警。实验成果如图27所示。图27实验成果第6章结论6.1本文结论随着经济的快速发展，汽车已经成为通用的交通工具，但如今由于汽车本身故障原因而引起大量的交通事故，为了减少该现象的发生，人们开始研究一种能够检测出故障的仪器，而本文研究的是基于Freescale单片机的诊断盒。（1）理论阶段：从网上查阅了诊断盒的相关资料，初步了解到了诊断盒主要是设计到的相关知识以及能够测量的相关参数，接着了解了大量的国内外发展状况和OBD-Ⅱ相关协议，并通过前期的工厂实习以及对相关事物的拆除，进一步完成了前期材料。（2）设计阶段：该阶段主要分为两个部分，一为硬件设计部分，二为软件设计部分。硬件设计部分，考虑到车辆电源与设计时用到的电路元件电压不符合，因此设计了一个能够将高电压降低的模块，要从汽车ECU中获取故障信息，即选用了CAN模块，对信息的获取、解析和发送，同时设计了一个显示屏和蜂鸣器模块，显示屏显示车辆故障代码，蜂鸣器在诊断出故障时及时向使用者发出警示报警；软件部分，主要是对运用CodeWarrior软件，对每个模块进行代码的编写，从而实现一系列的诊断过程。（3）实验阶段：将编写好的代码导入设计好的电路板块中