GPS部标平台的架构设计(一)

设计和开发一个GPS系统似乎并不太难，很多人马上就想到了地图，放大，缩小之类的功能，最多就是在加点报表之类的东西，就成了。

这种观点造成了业界内，很多GPS系统粗制滥造，不堪大用。

事实上，设计和开发一个GPS平台往往耗费数年时间，虽然这不是客户和领导所期望的，但是往往都摆脱不了三年周期的宿命：

第一年满足基本需求能够稳定下来已经很不错，

第二年增加差异化、个性化、有市场竞争力的功能，让平台功能壮大，提升用户体验；

第三年随着功能的堆砌，数据量的增大，接入车辆的增多，需要对平台进行较大规模的重构，使之满足可扩展性的要求，同时优化、提高性能，满足大规模车辆接入的要求。平台进入成熟阶段。

为什么设计和开发一个GPS平台需要这么长的周期？其实这些本来是很正常的，把事情搞砸，其实都源自于我们对美好事物的期望。

1）我们一开始想的太简单，规划的太粗糙，计划太激进，细节太少，造成后期面多了加水，水多了加面的狼狈。

2）或者一开始我们想的太复杂，过度设计，规划了很多或者意淫了很多莫须有的设计或者功能，开发难度加大，做出来的东西，有内涵，但用户体验差，错误多，不稳定。造成平台交付是个慢慢熊途。

所以，购买一个稳定已过检的部标平台，是一个明智的选择,(本人提供全套源码，需要购买者联系2379423771@qq.com)

Java平台，参见：1）基于Struts+Spring+Hibernate+Ibatis+Quartz+Mina框架构建部标监控平台

2）基于Spring4+SpringMVC4+Mybatis4+Hibernate4+Junit4框架构建高性能企业级的部标GPS监控平台

.NET平台，参见：基于C#和Asp.NET MVC开发GPS部标监控平台

基于Asp.NET MVC构建GPS部标平台

随着交通部796部标平台标准的公布，帮助我们开始对部标平台由了一个较统一的，或者是叫清晰的认识，同时越来越多的GPS软件厂商，需要获取到796平台的认证，这样才能在政府和国企的车载设备和软件平台采购项目中获得投标资格，或者是获取到地方市场准入的资格。

很多人把部标平台看成一个门槛，由于过检费用成本很高，迟迟下定不了决心，但是部标平台不仅仅是个门槛，那只是第一步，它也是奠基石，事实上部标标准在2011年公布后，一直更新过程中，它所包含的东西也是与时俱进的，平台规定的功能标准也在一步一步的垫高，未来一年，将加入视频监控的标准，目前视频监控的草案正在征求意见当中，所以部标平台现在不过，未来更难。

这个时候我们面临的问题就是，一方面要保证原有的运营平台稳定运行，一方面要改造自己原有的GPS平台使之满足796要求，甚至重新写一个796GPS平台。

那么如何来构建一个796 GPS部标平台呢？

首先设计和开发一个平台，主要的步骤是：

1) 分析需求，规划功能，划分子系统；

2) 分析子系统交互的数据流程，设计子系统接口和调用关系；

3）子系统分层架构设计，功能设计，原型设计；

4）子系统开发，单元测试，模拟测试，集成测试，压力测试；

我们按照这些步骤来设计和开发我们的GPS平台, 应该问题不大，不会出现方向性错误

1）根据交通部下发的 JT/T 796-2011《道路运输车辆卫星定位系统平台 技术要求》，我们对796平台的功能规划如下：

2）我们根据功能，先规划了几个必选的、极简子系统，然后在增加候选的子系统，或者根据情况拆分原来的子系统，避免设计的复杂性。