日前，国家网信办针对当前“知识社区问答”的一些乱象，发布了“知识社区问答”行业主要问题及平台主体责任清单，旨在加强互联网“知识社区问答”信息服务的规范化，促进行业健康有序发展，保护公民、法人和其他组织的合法权益。

作为开发者社区平台，CSDN积极学习和响应管理规范，第一时间对全站内容及系统隐患进行了全面自查、排查和处理，同时CSDN承诺，将进一步深化落实知识社区问答平台管理责任，不断完善管理体系，为构筑健康网络空间贡献应尽的力量。

CSDN坚决维护网络信息安全，对违法违规内容零容忍。CSDN将在北京网信办指导下，进一步加强和健全平台内容安全管理制度和体系，落实平台管理责任。

 

CSDN号召所有用户，共同营造积极健康、科学真实、营养丰富的社区知识空间。欢迎广大用户反馈举报违法信息与行为，与CSDN一起共创健康向上的社区氛围，为健康的网络生态环境建设贡献一份力量！

举报电话：400-660-0108

举报邮箱：kefu@csdn.net

                                                                                                                                                                    CSDN 社区

                                                                                                                                                                     2020年11月6日

摘要
本发明公开了一种网络用户行为日志自动获取方法，其特征在于：在客户端与Web服务器之间加上一代理服务器，代理服务器第一次接受Web服务器返回的响应正文为HTML格式的用户响应即HTTP响应，在该HTTP响应中加入用户行为日志采集模块，发送到客户端，用户行为日志采集模块在客户端充当用户行为日志的数据采集端，而代理服务器充当用户行为日志的数据处理端。本发明基于中间“代理服务器”策略，重点解决了客户端日志捕获、代理服务器策略部署、日志获取的可视化配置等关键技术。与传统的日志记录的方案相比，本发明可以很好的关联用户，而且扩展性很好，通过可视化UI方便灵活的定制目标系统需要采集的用户行为日志，也可为进一步的日志挖掘提供数据基础。


技术领域 

本发明涉及一种网络资源获取方法，特别涉及一种网络用户行为日志的自 动获取方法。

背景技术

随着Web信息的日益增长，人们不得不花费大量的时间去搜索、浏览自己需 要的、感兴趣的信息。为解决此问题，自动识别用户兴趣，实现个性化的资源 推荐就成为个性化服务领域的研究热点。在这方面的研究也取得了显著的成就。 个性化服务研究大多数都是以用户访问行为的日志数据为基础开展研究，用户 访问行为的日志数据为个性化服务中用户兴趣发现、资源推荐等研究提供很好 的数据支持，是这些研究很关键的前提，而目前用户访问行为的日志获取方法 的研究仍不太成熟，可移植性很差，日志记录可重用性很低。目前用户访问行 为的日志获取方法如下：

第一种常见的日志获取方法是利用Web服务器日志进行过滤。Web服务器 日志记录了用户访问站点的数据，每当站点上的页面被访问一次，Web服务器 就在日志中增加一条相应的记录。

另外一种常见的日志获取方法，是嵌套在网站中，通过编写相应的日志记 录代码获取所需要采集的用户访问行为的日志数据。 上述现有系统在通信方面存在以下四方面的问题：

1. 日志记录不能很好的和用户关联起来；

2. 缺乏用户访问行为的定制，数据往往比较冗余繁杂；

3. 日志记录控制不能灵活的增加和减少需要采集的用户行为；

4. 对不同的系统，日志获取模块重用性很低。

发明内容

本发明的目的是解决现有技术日志获取中可扩展性和可移植性不高的缺

4陷，提供一种基于c/s (客户端/服务器）模式的可移植性较好的用户行为曰志

获取的方法。

为达到以上目的，本发明是采取如下技术方案予以实现的： 一种网络用户行为日志自动获取方法，其特征在于：在客户端与Web服务 器之间加上一代理服务器，代理服务器第一次接受Web服务器返回的响应正文 为HTML格式的用户响应即HTTP响应（HTTP响应包括三部分内容：响应状 态码，响应头部和响应正文），在该HTTP响应中加入用户行为日志采集模块， 发送到客户端，用户行为日志采集模块在客户端充当用户行为日志的数据采集 端，而代理服务器充当用户行为日志的数据处理端；引入代理服务器以后的信 息交换模式具体包括下述步骤：

1) 用户通过客户端向Web服务器发送HTTP请求；

2) 代理服务器截获该HTTP请求并解析该HTTP请求的类型，以决定是否 转发该HTTP请求，具体情况如下：

a. 当请求为调用Web服务器资源，则：

Stepl:代理服务器转发该请求至Web服务器； Step2:转至步骤3);

b. 当请求为调用用户行为日志采集模块，贝'J:

Stepl:代理服务器构建包含用户行为日志采集模块的HTTP响

应；

Step2:转至步骤5);

c. 当请求为发送采集的日志数据，贝'J:

Stepl:代理服务器接收发送的日志数据； Step2:日志数据交由代理服务器上的日志处理模块处理； Step3:处理后的日志数据储存到代理服务器的日志文件中； Step4:代理服务器构建包含接收日志数据成功标志的HTTP响应； Step5:转至步骤5);

3) 代理服务器接收来自Web服务器返回的HTTP响应并判断该HTTP 响应正文的类型：

a. 如果响应正文为HTML网页，转至步骤4);

b. 否则转至步骤5);4) 代理服务器解析HTTP响应，并在该响应中修改HTTP响应头部的长度 信息、在该响应正文中加入客户端日志采集模块；

5) 代理服务器将步骤2)包含用户行为日志采集模块的HTTP响应、包含 接收日志数据成功标志的HTTP响应、步骤3) Web服务器返回的HTTP响应或 者步骤4)修改后的HTTP响应发送至客户端。

上述方案中，所述代理服务器与原来的Web服务器为同一台服务器；或不 同于Web服务器，而作为一个独立的日志获取服务器。

所述用户行为日志采集模块采用事件驱动模型，代理服务器提供可视化用

户接口UI定制目标系统需要采集的用户行为，存储在用户行为描述文件中，当

用户定制完需要采集的行为之后，用户行为描述文件被存放到代理服务器上，

最后，在客户端充当用户行为日志数据采集端的用户行为日志采集模块动态加

载位于代理服务器上的用户行为描述文件，依据定制的用户行为来采集用户在

目标系统的这些行为日志数据。

其中每种用户行为可通过下述两种方法之一来描述:

① 通过用户在页面有序的操作序列集合来标识定制的行为；

② 通过统一资源定位符URL来过滤得到定制行为； 以上两种方式都可以唯一的标识某个行为。 与上述提到的背景技术作对比，我们来分析下本发明的优势。 不同的系统需要采集的行为往往有所不同，为了提高日志记录模块的可重

用性，这就需要提供一种机制灵活的增加或减少系统中需要采集的行为，并且 在用户行为日志采集过程中，需要灵活的配置和描述需要采集的行为。而且为 了适应更多的系统，除有一些基本的用户行为（如搜索行为，评价行为，浏览 行为等），还应可以定制一些其他行为。但目前日志记录并没有很好的对不同的 行为进行分类，也不能灵活的自定义系统需要采集的用户行为，更没有提供一 种有效的方法来描述一种用户行为。

本发明用户行为日志采集模块采用事件驱动模型，针对页面对用户行为进 行监听，它可以借助于浏览器直接运行，主要好处在于它允许更大的灵活性， 因为处理程序完全是独立的，当事件发生时，它只需要发送给统一的处理程序， 而不需要了解具体是哪个子程序在执行，哪个子程序是什么功能。

至于描述用户的行为，本发明提供了一个数据格式——用户行为的描述文 件，在这个文件中通过可扩展标记语言XML来描述和存储需采集的用户行为。并且提出每种行为可通过两种简单的方式来描述：该两种方式都可以唯一的标 识某个行为。有了上述用户行为描述文件，就可灵活的定制需要采集的用户行 为，并提供对用户行为的描述机制及方便用户配置的可视化用户接口 UI。最后 用户行为日志采集模块动态加载用户行为描述文件，而我们只需在用户行为描 述文件里增加或减少相应的行为即可达到灵活的增加或减少需要采集的用户行 为。

与现有技术的对比，本发明的特点是：

1. 实现可扩展的系统，灵活定制需要采集的用户行为；

2. 对不同的系统，该方法移植性较高；

3. 容易部署，从而为系统提供透明的日志记录服务；使后期的日志数据 预处理及数据挖掘更容易。

附图说明

图1为本发明方法涉及的网络系统框图。

图2为本发明用户行为日志数据采集端和用户行为日志数据处理端的设计 框架图。

图3为本发明用户行为日志采集模块可扩展的设计结构。

图4为本发明代理服务器的工作流程图。

图5为正常上网资源请求时序图。

图6为客户端对用户行为采集模块的请求时序图。

图7为客户端发送采集的行为日志时序图。

图8为用户行为日志采集基本行为配置图。













具体实施方式

为了更清楚的理解本发明，以下结合附图对本发明作进一步的详细描述。 如图1所示，在客户端与Web服务器之间加上一 "代理服务器"，用户通 过客户端向Web服务器发送请求；代理服务器截获该请求并转发至Web服务器； Web服务器返回HTTP响应至代理服务器;代理服务器处理Web服务器返回的HTTP 响应，并在该HTTP响应中加入用户行为日志采集模块，然后发送至客户端。 本发明釆用C/S模式，考虑可扩展，可移植这两个特性，用户行为日志获取的方法主要包括两方面的设计：用户行为日志的数据采集端和用户行为日志 的数据处理端（如图2所示）。以下予以分述：

①充当用户行为日志数据采集端的用户行为日志采集模块的设计（图2客户端）: 用户行为日志数据采集端主要是针对页面进行监听以捕获行为日志，为此 我们要采用客户端脚本语言JavaScript,该技术对页面元素能很好的支持，并且 扩展性要好，支持"事件驱动"。客户端脚本语言JavaScript是动态的，它可以 直接对用户或客户在页面的输入做出响应，无须经过Web服务程序；而且更重 要的它是采用以事件驱动的方式进行的；而且它是一种基于对象的语言，这样 可以使程序的可读性更高，维护起来很方便，而且易扩展；它还是跨平台的，
 只依赖于浏览器本身，与操作环境无关。

另外我们还需要一种交互式网页应用的网页开发技术用来把客户端捕获的 用户行为日志发送给用户行为日志的数据处理端。我们选用AJAX (异步 JavaScript和XML (可扩展标记语言））来满足这个需求，而且AJAX和客户端 脚本语言JavaScript结合性很好。客户端脚本语言JavaScript是一种粘合剂使 AJAX应用的各部分集成在一起。在AJAX中客户端脚本语言（如JavaScript) 主要被用来传递用户界面上的数据到服务端并返回结果。 下面进一步划分模块介绍： m关联用户

上面提到Web服务器日志缺乏用户ID这个重要信息，而且我们记录日志的 目的是要给用户分析其兴趣并为其推荐资源，所以我们一定要有能标识用户的 信息。在这通过捕获得到用户登录时的.ID来标识用户，如果用户匿名登录，则 以IP (网络协议）地址来标识该用户。 [2]动态加载用户行为描述文件

用户行为描述文件是通过可扩展标记语言XML文件进行描述的。每种行为 可通过下述两种方法之一来描述： 一种是按照页面元素标签的触发顺序来标志 某种行为； 一种是按照URL来过滤出某种行为。两种方式都可以唯一的标识某 个行为。我们加载用户行为描述文件，这样用户行为日志采集模块可以只捕获 用户行为描述文件中定制的这些行为操作。 [3]事件监听

事件监听模块使用事件驱动模型来实现，事件驱动模型的三大要素包括-事件源：能够接收外部事件的源体；侦听器：能够接收事件源通知的对象；事 件处理程序：用于处理事件的对象。我们给用户行为描述文件定制的这些用户 行为注册事件侦听器，并把事件侦听程序和事件处理程序独立开来。

我们以一个具体事例来解释事件驱动模型，如图3所示，当我们为一个特 定的按钮元素注册点击的事件侦听器，当用户点击这个按钮时，会将事件传递 给侦听器，这意味着事件源调用侦听器对象中的一个特定方法（侦听器对象可 以侦听一个特定对象的事件(比如一个按钮)），并以事件对象作为实参，然后交 给事件处理程序按照一定业务逻辑执行。 ②用户行为日志数据处理端的设计：

首先我们先了解一下充当用户行为日志数据处理端的"代理服务器"工作 流程（如图4所示）：

1) 用户通过客户端向Web服务器发送HTTP请求；

2) 代理服务器截获该HTTP请求并解析该HTTP请求的类型，以决定是否 转发该HTTP请求，具体情况如下：

a. 当请求为调用Web服务器资源，则：

Stepl:代理服务器转发该请求至Web服务器； Step2:转至步骤3);

b. 当请求为调用用户行为日志采集模块，贝'J:

Stepl:代理服务器构建包含用户行为日志采集模块的HTTP响

应；

Step2:转至步骤5);

c. 当请求为发送采集的日志数据，则：

Stepl:代理服务器接收发送的日志数据； Step2:日志数据交由代理服务器上的日志处理模块处理； Step3:处理后的日志数据储存到代理服务器的日志文件中； Step4:代理服务器构建包含接收日志数据成功标志的HTTP响应； Step5:转至步骤5);

3) 代理服务器接收来自Web服务器返回的HTTP响应并判断该HTTP

响应正文的类型：

a.如果响应正文为HTML网页，转至步骤4);b.否则转至步骤5);

4) 代理服务器解析HTTP响应，并在该响应中修改HTTP响应头部的长度 信息、在该响应正文中加入客户端日志采集模块；

5) 代理服务器将步骤2)包含用户行为日志采集模块的HTTP响应、包含 接收日志数据成功标志的HTTP响应、步骤3) Web服务器返回的HTTP响应或 者步骤4)修改后的HTTP响应发送至客户端。

我们使用socket (套接字）技术，通过监听客户端端口或Web服务器端口 实现上述流程。当用户自客户端通过浏览器发送HTTP请求时，代理服务器首 先接受客户端的连接，并建立一个新的线程，接收HTTP请求，并按照HTTP 协议的格式对HTTP请求和HTTP响应作简单的解析，以决定代理服务器是否 转发该请求、是否修改来自Web服务器的用户HTTP响应。

由于我们的主要目的是为了获取用户的日志数据。针对上述流程中步骤2) 中第c种情况进一步的描述（参见图2中用户行为日志数据处理端），每当用户 行为日志数据采集端向用户行为日志数据处理端发送捕获到的行为记录时，用 户行为日志数据处理端会给其分配一个接收数据线程，当多条行为记录同时发 送时，则采用多线程并行处理以加快执行速度，之后接收数据线程会将数据交 由曰志数据处理器，由数据处理器按照日志格式对接收到的数据进行处理并将 处理后的用户行为日志数据存储到日志数据库中。

另外我们提到代理服务器提供可视化用户接口UI方便用户定制目标系统需 要采集的行为(UI如图8所示)。

用户可以根据项目的需求定制一些在项目中要采集的行为。最后生成一个 定制目标系统需采集行为的用户行为描述文件。用户行为描述主要采用两种方 式： 一种是按照用户在页面有序的操作序列集合来标识定制的行为； 一种是按 照URL来过滤出定制的行为。

举例说明如下：搜索行为是通过用户在页面有序的操作序列来描述的。即 记录了用户在页面完成搜索行为需要执行的有序的操作集合。 一般搜索行为需 要两个有序的操作：输入关键字，提交査询内容。输入关键字这个操作关联页

面上输入关键字的文本框，提交查询内容这个操作关联页面上的提交按钮根据

超文本标记语言HTML的规范我们知道，页面元素由其id属性唯一标识。我们 通过有序集合A^输入关键字的文本框的id属性、提交按钮的id属性}就可以

10标识该搜索行为。

评价行为我们通过URL进行描述的。我们都知道URL为统一资源定位符 (UniformResourceLocator的縮写），它可以唯一的标识一个资源。首先给出评 价行为的URL，然后对其参数进行描述。 一般评价行为包含三个参数：评价资 源的用户的标识，被评价的资源的标识，评分。我们通过URL加上其参数就可 以标识该评价行为。

注：这个三个参数也是为了适应个性化服务中的推荐模型。

  网络爬虫的发展为使用者了解和收集网络信息提供便利的同时，也带来了许多大大小小的问题，甚至对网络安全造成了一定危害。所以，在真正开始了解网络爬虫之前，我们也需要先了解一下网络爬虫的特性、带来的问题以及开发和使用网络爬虫的过程中需要遵循的规范。


网络爬虫的尺寸分类




尺寸
特性
目的
实现方式




小规模
数据量较小，对爬取速度不敏感，数量非常多
爬取网页，探索网页信息
Requests库


中规模
数据量较大，对爬取速度较敏感
爬取网站和系列网站
Scrapy框架


大规模
数据量和规模极大，多用于搜索引擎，爬取速度极为关键
爬取所有Internet上的网站
定制



网络爬虫带来的问题
 系统负担
  由于技术限制和爬取目的，部分网络爬虫产生的网络负载远大于用户访问负载，这给网站造成了很大的带宽负担和Web服务器系统资源开销，为网站的正常运行造成一定的负担。所以对于网站的所有者来说，网络爬虫（特别是不规范运行的爬虫）给网站造成了一定的骚扰。
 法律风险
  由于网站上的数据一般具有产权归属，某些网络爬虫获取数据后如果进行分析贩卖牟取利益将给网站带来经济损失，同时为开发和使用者带来法律风险。所以网络爬虫的设计者在设计爬虫时要严格遵循互联网和企业关于爬虫的管理规定，否则可能承担一定后果。
 隐私泄露
  网站上可能存在部分所有者原本不想让用户访问到的隐私数据，部分网站可能使用较弱的访问控制来保护数据，但部分网络爬虫可能具有绕过或突破这类访问控制的能力。如果网站没有做好信息保护导致信息不慎泄露，就会引发严重的信息安全问题。

网络爬虫的规范

  由于网络爬虫可能会带来上述的问题，但同时网络爬虫本身并不是一个危害性的工具，所以Internet和各个网站都在给出限制条件的基础上允许网络爬虫的运行。下面，我们就来了解一下网站和互联网对爬虫的限制方式

 网络爬虫的限制方法
  来源审查
  部分网站使用较为简单的来源审查来进行访问限制。原理是通过分析网络请求中请求首部的User-Agent字段来筛选请求。网站只响应来自浏览器和友好爬虫的访问请求。来源审查对网站开发人员的技术水平有一定要求
  发布公告（Robots协议）
  网站使用发布公告的方法告知所有爬虫对这个网站的爬取策略，要求每一个爬取该网站的爬虫遵守。目前Internet上主流的公告协议是Robots协议，这个协议规定了网站中可以爬取和不可爬取的内容。这种方法更加简单，对网站开发人员的要求较低。但是，这种发布公告的方法部分情况下仅对爬虫开发者有道德限制，如果没有配合其他访问控制方式，如果爬虫有目的地访问，其能非常容易地找到隐私内容。但是违反该协议的爬虫的开发和使用者将面临很高的法律风险。我们在设计爬虫时也应该遵循这些公告的要求。
 Robots协议
Robots协议（Robots Exclusion Standard网络爬虫排除标准）通过放置在网站根目录下的robots.txt文件来告知网络爬虫哪些页面允许爬取而哪些不能。如果一个网站没有在根目录下提供这个文件，则默认允许网络上的所有爬虫爬取网站内容
  Robots协议格式
Robots协议内容主要由下列关键字、通配符与具体名称和路径构成




关键字、通配符
说明




User-agent:
对特定名称的爬虫的规定（开始）


Allow:
允许抓取的内容


Disallow:
禁止抓取的内容


*
通配符，指任意内容


$
通配符，指以前面内容为结尾



注意：关键字的冒号均为英文，冒号后有一个空格
User-agent关键字与爬虫请求中的User-agent首部字段向对应
针对不同爬虫的规则之间有一空行分隔
Allow关键字具有与Disallow关键字相反的作用，可以排除某些被其拒绝的子目录
如果没有需要禁止访问的网页，也应该写一行规则，一般在Disallow关键字的空格后直接换行（或在Allow关键字后使用/表示根目录）
?没有特殊含义，仅表示?字面意思

下面节选百度的robots.txt内容进行介绍。
User-agent: Baiduspider
Disallow: /baidu
Disallow: /s?
Disallow: /ulink?
Disallow: /link?
Disallow: /home/news/data/
Disallow: /bh

User-agent: Googlebot
Disallow: /baidu
Disallow: /s?
Disallow: /shifen/
Disallow: /homepage/
Disallow: /cpro
Disallow: /ulink?
Disallow: /link?
Disallow: /home/news/data/
Disallow: /bh

...

User-agent: *
Disallow: /

百度对Baiduspider百度搜索引擎主爬虫限制了特定的目录，而对Googlebot谷歌搜索引擎主爬虫限制了更多内容。在所有允许列表后有一个User-agent: *，并禁止根目录，表示百度网站禁止除了上述友好爬虫外的所有爬虫对网页的抓取。
  Robots协议的遵循方式
  网络爬虫应当能够自动或人工识别robots.txt文件内容，按照协议要求对网站进行爬取。虽然Robots协议对爬虫的运行规定仅是建议性的，但并不意味着不遵循该协议对网站的任意爬取不会存在任何法律风险。尤其是包含商业价值的内容，如果使用爬虫违规爬取获益，将可能面临被起诉风险。

  原则上来说，所有网络爬虫都应该遵循Robots协议规范。如果网络爬虫的访问量较大或者以商业利益为目的，则必须遵守Robots协议，但如果仅仅以个人非盈利目的，且对网站访问量较小，则可以适当减少协议的约束性。如果一个爬虫对网站的访问（频率和爬取内容）与用户的访问模式相当，则该类行为被称为类人行为，这类行为可不遵守Robots协议。

关于AUTOSAR的底层驱动、平台OS、平台应用、RTE、应用软件这些和VxWorks653很相似，就不多赘述了。

此处说一下AUTOSAR独有的网络通讯规范和网络管理模块NM

一、AUTOSAR COM

AUTOSAR COM是AUTOSAR标准的一部分，它是从OSEK COM标准的基础上发展而来的。AUTOSAR COM提供了一种标准化的访问汽车通讯系统和ECU（Electronic Control Unit）通讯的方式，提出了一个在不同速率的总线网络之间进行数据交换的方法。它为汽车控制单元应用软件提供了一个统一的通信环境，为内部和外部通信定义了公共的软件通信接口和行为，增强了应用软件模块的可移植性。

依据AUTOSAR的描述，这个跟IMA的RDIU很类似。实现不同数据协议和速率的数据的相互装换，然后发向目的ECU。

AUTOSAR COM提供了基本的通信服务，它有明确的上层模块RTE(Runtime Environment)和下层模块PDU Router。

在发送过程中，应用层调用COM层提供的信号或信号组发送函数，根据配置，信号或信号组的数据经过字节顺序转换后被更新到I-PDU（Interaction Layer Protocol Data Unit）中相应的位置中。AUTOSAR COM规范中同一I-PDU可以设置两种发送模式，对其中各信号的传输模式条件进行计算，I-PDU选择其中一种发送模式进行发送。然后启动发送死限监控，调用PduR_ComTransmit()函数将I-PDU发送到底层。


	
在接收过程中，当底层接收到I-PDU时，底层将调用COM层提供的指示函数Com_RxIndication()，取消并重启接收死限监控，将I-PDU的数据从底层拷贝到COM中。调用信号或信号组的接收函数后，该I-PDU中的信号或信号组将经过字节顺序转换、符号扩展和接收过滤后，数据被拷贝到应用层。
	
	
通信系统核心模块的实现
	
通信系统主要实现信号或信号组的收发功能，以下主要介绍信号发送的实现。首先简要介绍一下AUTOSAR COM中特有的传输模式切换。
	传输模式切换

	
AUTOSAR COM规范定义了4种信号传输模式：

	
直接/N次传输模式
		
周期传输模式
		
混合传输模式
		
None传输模式。
	
在AUTOSAR COM规范中允许为每个I-PDU静态配置两种不同的传输模式。

	
在AUTOSAR COM规范中通过传输模式切换，来选择I-PDU中的其中一种传输模式进行传输。

	
首先使用过滤机制判断I-PDU中各信号的发送模式条件，同时更新I-PDU中的信号；
		
再通过各信号的判断结果来计算该I-PDU的TMS（transmission mode selector）。若至少有一个C( Si,IPDUk)为True，则TMS为True；若所有C(Si,IPDUk)都为False，则TMS为False。其中C(Si,IPDUk)为传输模式条件该条件与IPDUk中的信号Si相关。
	
 

 

下面通过一个用例简要说明传输模式的切换。

用例中进行周期传输和直接/N次传输之间的切换（N=3）。

根据I-PDU的传输配置，当TMS（transmission mode selector）判断为真时，设置传输模式为周期传输，反之为直接/N次传输。上层给定值V=a（此时TMS判断为真），进行周期传输；当值V更新为b时（此时TMS判断为假），进行直接/N次传输模式，传输三次。由图3可知，随着V值的更新该I-PDU的传输模式在这两种传输模式之间切换。

信号发送的实现

首先根据该信号的相关配置，判定其是内部消息还是外部消息。
	
对于内部发送，直接将信号数据复制到接收信号数据区，并执行通知操作；
	
对于外部发送，若该信号发送属性为触发，则该信号所属的I-PDU将立即发送（除非该I-PDU发送模式为周期传输模式），若该信号发送属性为延迟，则不进行传输，发送时，信号经过字节顺序转换后数据被复制到I-PDU中，同时设置相关更新位信息，然后根据该I-PDU的TMS切换传输模式，进行传输并设置启动相关定时器。各传输模式的传输过程与OSEK COM中大致相同。
信号接收的实现

首先判定是内部信号还是外部信号。
	
对于内部接收，直接将信号数据复制到接收信号数据区；
	
对于外部接收，首先判断对于的I-PDU组是否启动，若启动，返回E_OK，否则返回COM_STOP，取消并重启该I-PDU的相关死限监控定时器，将数据复制到I-PDU数据区，I-PDU中的信号经过字节书序转换、符号扩展和过滤机制后，复制到接收信号数据区，再执行通知操作，通知上层软件调用相关API函数接收信号。
 

二. 网络管理NM

这里的NM主要是针对Can协议的网路管理。

AUTOSAR CanNM的核心思想主要归纳为以下两条：

1.  如果节点需要保持通信，则节点需要周期的发送NMPDUs，否则停止发送NMPDUs

2.     如果总线上的所有节点不需要使用总线，那么总线上过了一段时间没有NMPDUs时，则会进入Bus-Sleep Mode。

 

工作模式和状态

 

CanNm一共有三个工作模式

1.  Network Mode

2.  PrepareBus-Sleep Mode

3.  Bus-Sleep Mode

模式的改变应该通过回调函数通知上层。

下面单独说每种模式

 

（1）Network Mode

Network Mode又包括三个内部状态

1. Repeat Message State

2. Normal Operation State

3. Ready Sleep State

①Repeat Message State

这个模式被用来确保从Bus-Sleep or Prepare Bus-Sleep到Network Mode的节点被总线上面其他节点发现。这个状态可以用来检测总线上的节点。

当进入Repeat Message State时，节点应该开始传送NMPDUs。

在Repeat Message State时，当NM-Timeout Timer溢出，CanNm模块应该重载Timer。

CanNm模块应该在Repeat Message State 下保持一段时间，这段时间可以通过CANNM_REPEAT_MESSAGE_TIME来进行配置。

当离开Repeat Message State的时候，如果节点需要通信，则进入Normal Operation State；如果节点不需要通信，则进入Ready Sleep State。并且清空Repeat Message Bit。

 

②Normal Operation State

这个状态可以保持总线处于唤醒状态。从Ready sleep state进入这个状态的时候应该发送NMPDUs。

在Normal Operation State当NM-Timeout Timer溢出，CanNm模块应该重载Timer。

如果节点不需要使用通信，则网络应该被释放，节点应该进入Ready Sleep State。

如果节点接收到Repeat Message Request Bit，则节点进入Repeat Message State。如果节点自身需要进入Repeat Message State，则该节点进入Repeat Message State并且设置Repeat Message Request Bit。

 

③ReadySleep State

这个状态是为了如果本节点已经准备释放总线，而其他节点还需要使用总线的时候，在这个状态下等待其他总线上的节点进入Perpere Bus-Sleep Mode。进入这个状态之后，CanNm模块应该停止NMPDUs的传送。

如果NM-Timeout Timer溢出，节点将会进入Prepare Bus-Sleep Mode。

如果该节点需要使用总线，则节点进入Nomal Operation State。

如果节点接收到Repeat Message Request Bit，则节点进入Repeat Message State。如果节点自身需要进入Repeat Message State，则该节点进入Repeat Message State并且设置Repeat Message Request Bit。

（2）PrepareBus-Sleep Mode

 

这个状态是为了等待总线上的所有节点能够在进入Bus-Sleep Mode之前，有时间停止节点的active状态如清空队列中为发送的报文。在Prepare Bus –Sleep Mode下，所有节点都静默下来。

当节点进入PrepareBus Mode时，应该通知上层应用。通过配置CANNM_WAIT_BUS_SLEEP_TIME参数，可以改变节点在PrepareBus-Sleep Mode停留的时间，在这段时间之后节点将会进入其他状态。

在Prepare Bus-Sleep Mode下面接收到NMPDU或者被上层应用请求通信时，节点将进入Network Mode中的Normal operation State。

 

（3）Bus-SleepMode

 

Bus-Sleep Mode的目的是当没有消息被传送的时候可以减少能量的消耗。在Bus-Sleep Mode下面，节点可以被唤醒（如本地唤醒源和CAN线唤醒源）。CANNM_TIMEOUT_TIME+CANNM_WAIT_BUS_SLEEP_TIME两个参数在整个总线上面的节点都应该时一样的配置，保证了总线上的节点能够统一的进行休眠。

当进入Bus-Sleep Mode时候，应该通知上层应用。

在Bus-Sleep Mode下，如果成功接收到NMPDU，CAN NM模块应该调用Nm_NetworkStartIndication。

如果CanNm_PassiveStartUp被调用，则CAN NM模块进入Network Mode 中的Repeat Message State。

 

参考资料：http://bbs.cirmall.com/thread-50513-1-1.html