<commit_before>---
layout: post
title:  "J1939 快速入门" 
date:   2019-03-31 22:05:00
categories: 学习笔记
tags: 汽车电子 J1939 CAN 
excerpt: 本文特别适合于对CAN有了解，对J1939不了解但是想了解的小伙伴。
mathjax: true
---

### J1939 介绍

SAE J1939协议是基于CAN2.0B协议之上的应用层协议，但是SAE J1939协议并不仅仅是个应用层协议，她对物理层，数据链路层，网络层，应用层，故障诊断，
网络层管理层等都做了详细的规定,只不过这其中很多规定都跟CAN2.0B一致。我们这里只介绍J1939的应用层，对软件开发来说已经足够。
对熟悉CAN2.0B协议的小伙伴来说，其实只要掌握下面几个关键点，J1939就瞬间不再神秘。

- J1939协议是基于CAN2.0B的应用层协议，所有J1939报文都是使用29位标志符。

CAN报文中我们有11位标志符的标准帧也有29位标志符的扩展帧，在J1939协议中，我们所有报文都是29位标志符, 数据域则跟CAN报文的数据没有区别。

- CAN报文是基于ID的，而J1939协议是基于PGN的。

这一点几乎就是J1939协议的全部内容。CAN2.0B使用29位的标志符来区分不同的报文，J1939对这29标志符进行了重新的分类和解释。打个不是很恰当的比方，
以前CAN2.0B协议根据人的体重来区分不同的人，只要一样重(ID)就认为是相同的人群，体重越瘦的就越是受CAN2.0B协议喜欢(优先级越高),现在J1939也是测量体重，
只不过是把人的脑袋，躯干，双手，双腿分别测量，然后对这几个重量进行某种运算(比如脑袋重量的平方，躯干重量与双手重量乘积，以及双腿重量这三个数字之和),
只要运算的结果(PGN)一致，就认为这些人是一个人群。

也就是说,J1939对CAN2.0B中的29位标志进行了重新解释,我们使用下面这张图来说明一下:   

![]({{site.url}}/assets/J1939/PDU.png)

J1939对CAN ID进行了重新划分，加上最多8个字节的数据域，构成了J1939 的协议数据单元(Protocol Data Unit, PDU)，其中前3位表示优先级位(Priority, P)，
之后是扩展数据页位(Extended Data Page, EDP),数据页位(Data Page,DP), PDU格式位(PDU Format, PF), PDU特定域位(PDU Specific, PS), 
源地址位(Source Address,SA) 以及数据域(Data Filed)。

J1939的协议数据单元与CAN 报文帧相比要少一部分，比如SOF, SRR, IDE等，这是因为这部分完全由CAN 2.0B控制，J1939并未对这部分做任何修改。
J1939与CAN报文帧的对比可参考下图:

![]({{site.url}}/assets/J1939/sae-j1939-pgn.jpg)

如上图所示，J1939重新划分了29位的CAN ID,中间18位共同组成了参数组编号(Parameter Group Number, PGN),在CAN 报文中，我们根据CAN ID来区分不同报文，在J1939中，
我们根据PGN来区分不同的报文。J1939-71中对不同的PGN做了一系列详细的规定，不同的PGN来表示不同的数据或者功能。J1939-71对PGN的规定非常详细,足足有六百多页，
对于用户来说，可能熟悉自己常用的一些PGN就足够了，具体需要某些功能时去查询就好了。

**总结一下就是，J1939跟CAN 2.0B不同的地方就在于，J1939是以PGN为中心，通过不同的PGN来区分不同的类型,比如有些PGN传输控制命令，有些PGN传输数据，
有些传输请求，有些传输相应等等。在使用CAN传输数据时，CAN协议往往是我们自己定义的，<commit_msg>modified bugs and title in J1939<commit_after>---
layout: post
title:  "J1939 入门教程" 
date:   2019-03-31 22:05:00
categories: 学习笔记
tags: 汽车电子 J1939 CAN 
excerpt: 本文特别适合于对CAN有了解，对J1939不了解但是想了解的小伙伴。
mathjax: true
---

### J1939 介绍

SAE J1939协议是基于CAN2.0B协议之上的应用层协议，但是SAE J1939协议并不仅仅是个应用层协议，她对物理层，数据链路层，网络层，应用层，故障诊断，
网络层管理层等都做了详细的规定,只不过这其中很多规定都跟CAN2.0B一致。我们这里只介绍J1939的应用层，对软件开发来说已经足够。
对熟悉CAN2.0B协议的小伙伴来说，其实只要掌握下面几个关键点，J1939就瞬间不再神秘。

- J1939协议是基于CAN2.0B的应用层协议，所有J1939报文都是使用29位标志符。

CAN报文中我们有11位标志符的标准帧也有29位标志符的扩展帧，在J1939协议中，我们所有报文都是29位标志符, 数据域则跟CAN报文的数据没有区别。

- CAN报文是基于ID的，而J1939协议是基于PGN的。

这一点几乎就是J1939协议的全部内容。CAN2.0B使用29位的标志符来区分不同的报文，J1939对这29标志符进行了重新的分类和解释。打个不是很恰当的比方，
以前CAN2.0B协议根据人的体重来区分不同的人，只要一样重(ID)就认为是相同的人群，体重越瘦的就越是受CAN2.0B协议喜欢(优先级越高),现在J1939也是测量体重，
只不过是把人的脑袋，躯干，双手，双腿分别测量，然后对这几个重量进行某种运算(比如脑袋重量的平方，躯干重量与双手重量乘积，以及双腿重量这三个数字之和),
只要运算的结果(PGN)一致，就认为这些人是一个人群。

也就是说,J1939对CAN2.0B中的29位标志进行了重新解释,我们使用下面这张图来说明一下:   

![]({{site.url}}/assets/J1939/PDU.png)

J1939对CAN ID进行了重新划分，加上最多8个字节的数据域，构成了J1939 的协议数据单元(Protocol Data Unit, PDU)，其中前3位表示优先级位(Priority, P)，
之后是扩展数据页位(Extended Data Page, EDP),数据页位(Data Page,DP), PDU格式位(PDU Format, PF), PDU特定域位(PDU Specific, PS), 
源地址位(Source Address,SA) 以及数据域(Data Filed)。

J1939的协议数据单元与CAN 报文帧相比要少一部分，比如SOF, SRR, IDE等，这是因为这部分完全由CAN 2.0B控制，J1939并未对这部分做任何修改。
J1939与CAN报文帧的对比可参考下图:

![]({{site.url}}/assets/J1939/sae-j1939-pgn.jpg)

如上图所示，J1939重新划分了29位的CAN ID,中间18位共同组成了参数组编号(Parameter Group Number, PGN),在CAN 报文中，我们根据CAN ID来区分不同报文，在J1939中，
我们根据PGN来区分不同的报文。J1939-71中对不同的PGN做了一系列详细的规定，不同的PGN来表示不同的数据或者功能。J1939-71对PGN的规定非常详细,足足有六百多页，
对于用户来说，可能熟悉自己常用的一些PGN就足够了，具体需要某些功能时去查询就好了。

**总结一下就是，J1939跟CAN 2.0B不同的地方就在于，J1939是以PGN为中心，通过不同的PGN来区分不同的类型,比如有些PGN传输控制命令，有些PGN传输数据，
有些传输请求，有些传输响应等等。在使用CAN传输数据时，CAN协议往往是我们自己定义的，
{'fraction_non_alphanumeric': 0.10947002606429192, 'fraction_numerical': 0.10425716768027801, 'mean_word_length': 11.424460431654676, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2257805', 'n_tokens_mistral': 2898, 'n_tokens_neox': 3031, 'n_words': 158}