总体来讲，GPS部标平台的软件开发是一个对网络通信和应用程序之间通信的技术应用密集型的开发工作，也是有一定设计技术含量的工作。
1.设计通信接口
在设计的时候，根据职责划分，拆分成不同的应用子系统，对各个子系统进行功能隔离，并通过设计接口规定子系统直接的调用规约。
首先我们根据部标平台的要求，设计和开发出各个主要的服务器子系统，这是平台中最核心的子系统，在实际的应用中，由于车辆规模的大小和行业需求，还会扩展出各种业务子系统。核心子系统如下：
1)808GPS服务器，采用交通部的部标808协议，负责与终端的数据接收、指令下发; 参见：基于部标JT/T 808协议及数据格式的GPS服务器
2)809转发服务器，采用交通部的部标809协议，作为企业下级平台，负责转发GPS数据到*平台的服务器;参见:基于JT/T809-2011的(已过检)GPS平台数据交换及转发服务器
3)809*服务器，采用交通部的部标809协议，作为*上级平台，负责与下级平台进行全双工通信。
4)GPS监控客户端，采用自定义的数据通信协议与服务器进行数据通信，为用户提供监控UI，各种监控功能都直接反映在此客户端上。交通部的部标检测和认证的所有工作，虽然涉及了平台的各个部分，但是检测的发起都是从客户端发起的，其他的子系统，我们统称为后台。需要购买部标平台源码的可以联系(2379423771@qq.com)
2.接下来，我们需要确定子系统直接的通信框架。
很多老牌的GPS程序员，对于Socekt特别熟悉，只要是通信，就设计协议，然后使用Socket框架，里面侵入了大量的业务逻辑。时间长了，代码非常难以维护。
现在开发技术的发展似乎与他们绝缘。连WebService都少用。更不用说瑞士军刀WCF框架了。这种面向字节的设计和开发，常常要重复编写大量的二进制字节转换，而现在我们更喜欢的是面向接口的设计和开发，底层的东西我们已经不需要考虑，通过简单的配置就可以快速的构建出两个应用程序之间的数据通信。采用WCF，可以让我们基本摆脱掉那些令人厌恶的Socket套路。
比如我们再808中，设计一个实时数据服务，RealDataService和接口IRealDataService， 编写一个获取实时数据的方法，通过WCF框架的配置，就可以快速的为其他子系统提供实时数据的推送和转发服务了。
而且，我们也可以通过配置，将WCF转换成JSON格式，这样手机查车等手机客户端引用也可以和服务器进行数据通信，获取数据。
3.全双工通信
实际上子系统的通信基本全是全双工的通信，比如拍照的通信：809下级平台服务器收到上级平台的拍照指令后，将指令下发808服务器，808服务器再下发给终端，终端拍照应答给808服务器，808服务器再将拍照数据转发给809下级平台，809下级平台再将拍照数据转发给809上级平台。虽然我们描述流程的时候，仿佛是同步的，实际上网络通信是异步的全双工通信。可以看出部标要求的通信需求决定了子系统之间的通信的复杂性，而WCF的通信框架较好的隐藏掉底部通信的复杂性，满足顶层业务开发的需求。
4）部标流程检测和运行检测
部标平台开发的复杂性就在于，我们可以快速开发出一个大面上过得去的东西，但是却无法开发出一个严格符合要求的部标平台，从上图中可以看出一个拍照指令，需要贯穿四个子系统，并且是异步的。如何跟踪各种指令在横跨各个子系统或平台时的发送状态、执行状态和应答状态，不仅仅是一个需要在用户体验上面下功夫的功能，在交通部的部标认证的检测中，最最麻烦的就是运行检测，因为要跨两个平台，*平台和企业平台，企业平台内部要跨越终端、808服务器、809下级平台服务器等多个子系统。检测失败，可能出现在各个环节当中，检测人员只是平静的告诉你没有通过，而我们剩下就是猜了。所以每个系统必须要有较好的指令监控的功能，以便于较好的应对实际的部标检测中出现的意外情况。以下是对809转发服务器的指令的数据包监控。
