校讯通公话软件接口规范
（V1.4）
目录
1介绍 (4)
1.1目的 (4)
1.2适用范围 (4)
1.3缩略语 (4)
2接口协议概述 (5)
2.1GPRS协议 (5)
2.2接口分类 (5)
2.2.1普通公话接口 (5)
2.2.2校园数据库接口 (5)
2.2.3公话管理接口 (5)
3数据类型和格式定义 (6)
3.1数据类型定义 (6)
3.2PDU格式概述 (6)
3.3UASP PDU布局 (6)
4公话PDU接口定义 (8)
4.1“PHONE_AUTHEN”公话认证 (8)
4.1.1公话认证(由公话发给Server端) (8)
4.1.2公话认证应答(由Server发给公话) (8)
4.2“STDT_CAR D_LOGIN”学生卡登录操作 (8)
4.2.1学生卡登录请求语法(由公话发给Server端) (8)
4.2.2学生卡登录应答语法(由Server发给公话) (8)
4.3“STDT_NO_LOGIN”学号登录操作 (9)
4.3.1学号登录请求语法(由公话发给Server端) (9)
4.3.2学号登录应答语法(由Server发给公话端) (9)
4.4“STDT_READ_MSG”学生卡读取留言操作 (9)
4.4.1学生卡读取留言请求语法(由公话发给Server端) (9)
4.4.2学生卡读取留言应答语法(由Server发给公话) (10)
4.5“CALL_BILLING”通话话单操作 (10)
4.5.1通话话单请求语法(由公话发给Server端) (10)
4.5.2通话话单应答语法(由Server发给公话) (10)
4.6“STDT_SIGN_RECS”学生签到记录 (11)
4.6.1学生签到记录请求语法(由公话发给Server端) (11)
4.6.2学生签到记录应答语法(由Server发给公话) (11)
4.7“CONNECT_STATUS”网络连接状态查询 (11)
4.7.1网络连接状态查询语法(由公话发给Server端) (11)
4.7.2网络连接状态查询应答语法(由Server发给公话) (11)
5公话管理接口定义 (12)
5.1“ABT_STATUS”公话状态查询 (12)
5.1.1公话状态查询语法(由Server端发给公话) (12)
5.1.2公话状态查询应答语法(由公话发给Server) (12)
5.2“EDIT_ABT_SET”修改终端设置 (13)
5.2.1修改终端参数请求语法(由Server发给公话) (13)
5.2.2修改终端参数应答语法(由公话发给Server) (13)
5.3“SET_ABT_RESET”设置终端重启 (13)
5.3.1设置终端重启请求语法(由Server发给公话) (13)
5.3.2设置终端重启应答语法(由公话发给Server) (14)
5.4“UPDATE_NOTICE”程序更新通知 (14)
5.4.1程序更新通知语法(由Server端发给公话) (14)
5.4.2程序更新通知应答语法(由公话发给Server) (14)
5.5“UPDATE_PROGRAM”程序更新 (14)
5.5.1程序更新语法(由Server端发给公话) (14)
5.5.2程序更新应答语法(由公话发给Server) (15)
5.6“SYNC_ID_UPDA TE”亲情号码更新同步 (15)
5.6.1亲情号码更新同步请求语法(由Server发给公话) (15)
5.6.2亲情号码更新同步应答语法(由公话发给Server) (15)
5.7“SEND_ID_UPDA TE”亲情号码更新数据发送 (15)
5.7.1亲情号码更新数据发送请求语法(由Server发给公话) (15)
5.7.2亲情号码更新数据发送应答语法(由公话发给Server) (16)
5.8“ID_DELETE_ALL”亲情号码删除（全部删除） (16)
5.8.1亲情号码删除请求语法(由Server发给公话) (16)
5.8.2亲情号码删除应答语法(由公话发给Server) (16)
5.9“ID_DELETE_ONE”亲情号码删除卡信息（删除某个卡的卡信息） (16)
5.9.1亲情号码删除卡信息请求语法(由Server发给公话) (16)
5.9.2亲情号码删除卡信息应答语法(由公话发给Server) (16)
5.10“SET_TALK_DURATION”设置单次通话时长 (17)
5.10.1设置单次通话时长请求语法(由Server发给公话) (17)
5.10.2设置单次通话时长应答语法(由公话发给Server) (17)
5.11“CLASS_LIST”班级列表 (17)
5.11.1班级列表请求语法(由公话发给Server) (17)
5.11.2班级列表应答语法(由Server发给公话) (17)
5.12“STUDENT_LIST”学生列表 (17)
5.12.1学生列表请求语法(由公话发给Server) (17)
5.12.2学生列表应答语法(由Server发给公话) (18)
5.13“TEACHER_CALL_BILLING”教师通话话单操作 (18)
5.13.1教师通话话单请求语法(由公话发给Server) (18)
5.13.2教师通话话单应答语法(由Server发给公话) (18)
5.14“ME_STATUS_UPDATE”终端状态上报 (18)
5.14.1终端状态上报请求语法(由公话发给Server) (18)
5.14.2终端状态上报应答语法(由Server发给公话) (19)
5.15“STDT_BUS_SIGN”学生校车签到。 (19)
5.15.1学生签到记录请求语法(由公话发给Server端) (19)
5.15.2学生签到记录应答语法(由Server发给公话) (19)
6参数取值定义 (21)
6.1功能号（func_no）取值 (21)
1介绍
1.1 目的
中国移动校讯通业务可允许用户在学校使用公话享受移动服务。校讯通公话接口协议定义了校讯通业务中校园公话与校讯通公话服务器之间的接口协议及公话与读卡器的通讯协议。
校讯通公话接口采用GPRS或有线的通讯方式。
1.2 适用范围
本文定义了校讯通公话接口协议，规定了请求应答的会话方式、报文格式和语法，适用于外部实体开发商利用校讯通公话接口访问校讯通公话服务时参考。
1.3 缩略语
●SC (Service Center)：数据采集中心
●ABT (Child-caring System Teminal)：校讯通公话终端
●SRFC (Student RF Card)：学生专用的RF卡
2接口协议概述
2.1 GPRS协议
●校讯通公话接口采用GPRS协议与移动SC进行数据通讯。本质上是基于TCP/IP
协议之上的应用层协议，以TCP协议进行数据传输，采用请求/应答的同步通讯模
型实现。
●SC使用公网地址，在某个端口侦听校讯通公话连接，可以使用认证方式建立连接。
2.2 接口分类
公话接口分为以下几类：
2.2.1普通公话接口
提供普通公话服务。如校讯通卡登录，读取留言，通话话单上传等。
2.2.2校园数据库接口
校园学校签到/刷卡设备使用。
2.2.3公话管理接口
提供公话设备的系统管理接口。包括更新通知，程序更新，公话状态查询等。
3数据类型和格式定义3.1 数据类型定义
3.2 PDU格式概述
一个典型的信息格式如下表所示：
3.3 UASP PDU布局
下面是一个完整PDU的布局：
注：seq_no字段在同步中也可以使用，使用该字段作为请求包和响应包的对应字段。任何交易发起时，由client端产生seq_no，server收到请求后在响应包头中填入此字段内容，client端收到响应后，同发送包的该字段内容进行校验，以确认是该发送包的响应，然后继续处理。
4公话PDU接口定义
4.1 “PHONE_AUTHEN”公话认证
4.1.1公话认证(由公话发给Server端)
4.1.2公话认证应答(由Server发给公话)
的交互动作。
2.如果终端在未认证时连接进来,SEVER端要发送认证失败的包给公话,然后再断开连接
（可防止未知设备连到服务器）。
4.2 “STDT_CARD_LOGIN”学生卡登录操作
4.2.1学生卡登录请求语法(由公话发给Server端)
注：1.学生卡号以十六进制上传。
2学生ID字段和公话手机号字段暂时保留，服务器收到这两个字段暂时不处理4.2.2学生卡登录应答语法(由Server发给公话)
注：如果亲情号码个数为０，则亲情号码列表和关系不用发送，n=0。
4.3 “STDT_NO_LOGIN”学号登录操作
4.3.1学号登录请求语法(由公话发给Server端)
4.3.2学号登录应答语法(由Server发给公话端)
4.4 “STDT_READ_MSG”学生卡读取留言操作4.4.1学生卡读取留言请求语法(由公话发给Server端)
4.4.2学生卡读取留言应答语法(由Server发给公话)
4.5 “CALL_BILLING”通话话单操作
4.5.1通话话单请求语法(由公话发给Server端)
注：学生ID字段和暂时保留，服务器收到这两个字段暂时不处理
4.5.2通话话单应答语法(由Server发给公话)
注：话单包由终端发出后T秒未收到响应，终端应该立即重发，或终端发送不成功，Ｔ秒后应该立即重发，建议T=30。
4.6 “STDT_SIGN_RECS”学生签到记录
4.6.1学生签到记录请求语法(由公话发给Server端)
4.6.2学生签到记录应答语法(由Server发给公话)
注：签到包由终端发出后T秒未收到响应，终端应该立即重发，或终端发送不成功，Ｔ秒后应该立即重发，建议T=30。为了提高签到包的发送效率，建议采用并发方式发送，加以滑动窗口流量控制，滑动窗口参数W可配置，建议W=10，即接收方在应答前一次收到的消息最多不超过10个包（流量控制在1K字节以内）。
4.7 “CONNECT_STATUS”网络连接状态查询
4.7.1网络连接状态查询语法(由公话发给Server端)
4.7.2网络连接状态查询应答语法(由Server发给公话)
注：当信道上没有数据传输时，通信双方应每隔时间C发送链路检测包以维持此连接，当链路检测包发出超时时间T后未收到响应，应立即再发送链路检测包，再连续发送N-1次后仍未得到响应则断开此连接。现阶段建议取值为：C=３分钟，T=60秒，N=3。
4.8 “STDT_REMOTE_SIGN”学生签到记录
4.8.1学生签到记录请求语法(由公话发给Server端)
4.8.2学生签到记录应答语法(由Server发给公话)
注：签到包由终端发出后T秒未收到响应，终端应该立即重发，或终端发送不成功，Ｔ秒后应该立即重发，建议T=30。为了提高签到包的发送效率，建议采用并发方式发送，加以滑动窗口流量控制，滑动窗口参数W可配置，建议W=10，即接收方在应答前一次收到的消息最多不超过10个包（流量控制在1K字节以内）。
5公话管理接口定义
5.1 “ABT_STATUS”公话状态查询
5.1.1公话状态查询语法(由Server端发给公话)
5.1.2公话状态查询应答语法(由公话发给Server)
注:版本信息的格式为VERx.xx YYYY/MM/DD 例如(VER1.00 2004/05/10)
MinitorInfo前3个字节分别代表市电状态、手柄线状态、外壳门状态
第1个字节代表市电状态：1为外电，2为电池供电，3为电池电压低
第2个字节代表手柄线状态：1为正常状态，2为继线状态
第3个字节代表外壳门状态：1为关闭状态，2为打开状态
第55个字节到第72个字节（后18个字节）为短消息版本信息，格式为：VERx.xx YYYY/MM/DD 例如(VER1.00 2004/05/10)
5.2 “EDIT_ABT_SET”修改终端设置
5.2.1修改终端参数请求语法(由Server发给公话)
5.2.2修改终端参数应答语法(由公话发给Server)
5.3 “SET_ABT_RESET”设置终端重启
5.3.1设置终端重启请求语法(由Server发给公话)
5.3.2设置终端重启应答语法(由公话发给Server)
5.4 “UPDATE_NOTICE”程序更新通知
5.4.1程序更新通知语法(由Server端发给公话)
5.4.2程序更新通知应答语法(由公话发给Server)
5.5 “UPDATE_PROGRAM”程序更新
5.5.1程序更新语法(由Server端发给公话)
注：seq_no字段表示程序更新数据包的序号，从0开始,依次递增
5.5.2程序更新应答语法(由公话发给Server)
5.6 “SYNC_ID_UPDATE”亲情号码更新同步
5.6.1亲情号码更新同步请求语法(由Server发给公话)
注：每次亲情号码更新前，需先进行同步请求，有应答才发更新数据。
5.6.2亲情号码更新同步应答语法(由公话发给Server)
5.7 “SEND_ID_UPDATE”亲情号码更新数据发送
5.7.1亲情号码更新数据发送请求语法(由Server发给公话)
20条（数据包大小控制在1K内）。
5.7.2亲情号码更新数据发送应答语法(由公话发给Server)
5.8 “ID_DELETE_ALL”亲情号码删除（全部删除）
5.8.1亲情号码删除请求语法(由Server发给公话)
注：卡属性为０时，删除所有学生的卡信息，卡属性为１时，删除所有教师的卡信息5.8.2亲情号码删除应答语法(由公话发给Server)
5.9 “ID_DELETE_ONE”亲情号码删除卡信息（删除某个卡
的卡信息）
5.9.1亲情号码删除卡信息请求语法(由Server发给公话)
注：卡属性为０时，删除指定学生的卡ID信息，卡属性为１，删除指定教师的卡ID信息5.9.2亲情号码删除卡信息应答语法(由公话发给Server)
5.10 “SET_TALK_DURATION”设置单次通话时长5.10.1设置单次通话时长请求语法(由Server发给公话)
5.10.2设置单次通话时长应答语法(由公话发给Server)
5.11 “CLASS_LIST”班级列表
5.11.1班级列表请求语法(由公话发给Server)
5.11.2班级列表应答语法(由Server发给公话)
5.12 “STUDENT_LIST”学生列表
5.12.1学生列表请求语法(由公话发给Server)
5.12.2学生列表应答语法(由Server发给公话)
5.13 “TEACHER_CALL_BILLING”教师通话话单操作5.13.1教师通话话单请求语法(由公话发给Server)
5.13.2教师通话话单应答语法(由Server发给公话)
5.14 “ME_STATUS_UPDATE”终端状态上报
5.14.1终端状态上报请求语法(由公话发给Server)
注：终端状态上报默认24小时上报一个包，时间从第一次开机上报之后计算
5.14.2终端状态上报应答语法(由Server发给公话)
5.15 “STDT_BUS_SIGN”学生校车签到。
5.15.1学生签到记录请求语法(由公话发给Server端)
5.15.2学生签到记录应答语法(由Server发给公话)
注：签到包由终端发出后T秒未收到响应，终端应该立即重发，或终端发送不成功，Ｔ秒
后应该立即重发，建议T=30。为了提高签到包的发送效率，建议采用并发方式发送，加以滑动窗口流量控制，滑动窗口参数W可配置，建议W=10，即接收方在应答前一次收到的消息最多不超过10个包（流量控制在1K字节以内）。
目录 1接口类型 (2) 1.1人机接口 (2) 1.2软件-硬件接口 (2) 1.3软件接口 (2) 1.4通信接口 (2) 2接口设计规范 (2) 2.1基本内容 (2) 2.2规格说明 (3) 2.2.1人机接口 (3) 2.2.2软件-硬件接口 (3) 2.2.3软件接口 (3) 2.2.4通信接口 (3) 3接口设计文档提纲 (3)
1接口类型 1.1人机接口 人机接口是指计算机系统为完成人与机器之间互相传送信息而提供的功能的接口，包括硬件及程序。 1.2软件-硬件接口 软件-硬件接口是指软件系统中软件与硬件之间的接口。例如软件与接口设备之间的接口。 1.3软件接口 软件接口是软件系统中程序之间的接口。包括软件系统与其他系统或子系统之间的接口、程序模块之间的接口、程序单元之间的接口等。 1.4通信接口 通信接口是指处理机和标准通信子系统之间的接口。包括为实现数据通信用来完成接口功能的部件、装置及有关软件。 2接口设计规范 2.1基本内容 1、接口的名称标识 2、接口在该软件系统中的地位和作用 3、接口在该软件系统中与其他程序模块和接口之间的关系 4、接口的功能定义 5、接口的规格和技术要求，包括它们各自适用的标准、协议或约定 6、各个接口的数据特性 7、各个接口的资源要求，包括硬件支持、存储资源分配等 8、接口程序的数据处理要求
9、接口的特殊设计要求 10、接口对程序编制的要求 2.2规格说明 2.2.1人机接口 准确地说明人机接口的设计条件、设计特征、编程要求等技术内容。包括人机交互环境、人机接口部件、信息传输方式及传输特性、信息格式、数据处理、存储资源分配和程序编制要求等。 2.2.2软件-硬件接口 逐个描述每一个软件-硬件间接口的设计特性。包括接口硬件说明、接口功能说明、接口信息说明、接口处理方法、接口控制方式、接口时间特性、存储资源分配和程序编制要求等。 2.2.3软件接口 逐个说明本软件系统与其他软件系统间接口的设计特征。包括接口功能说明、接口约定、数据特性、数据处理方法、接口程序运行控制、接口时间特性、存储资源分配和程序编制要求等。 2.2.4通信接口 逐个描述各个通信接口的设计特性。包括硬件描述、接口功能说明、通信协议、报文处理、存储资源分配、程序接口设计和程序编制要求等。 3接口设计文档提纲 1概述........................................................................................................................................................... 错误！未定义书签。 1.1编写目的......................................................................................................................................... 错误！未定义书签。 1.2参考资料......................................................................................................................................... 错误！未定义书签。 1.3术语和缩写词................................................................................................................................ 错误！未定义书签。2软件系统综述......................................................................................................................................... 错误！未定义书签。3接口设计.................................................................................................................................................. 错误！未定义书签。 3.1接口框图......................................................................................................................................... 错误！未定义书签。 3.2接口一览表.................................................................................................................................... 错误！未定义书签。 3.3人机接口......................................................................................................................................... 错误！未定义书签。 3.4软件-硬件接口 .............................................................................................................................. 错误！未定义书签。
计算机联锁接口设计规 编写— 审核—___________ 版本—___________ 日期—____年___月___日
一、总则 (4) 二、采集、驱动信息说明 (5) (一)、基本采集信息： (5) (二)、特殊采集信息： (11) (三)、基本驱动信息： (12) (四)、防护用特殊驱动信息： (15) 三、需告知的容说明 (18) (一)、轨道停电 (18) (二)、引导总锁闭 (18) (三)、发车方向继电器 (18) (四)、接近延长 (18) (五)、点灯电路 (20) 四、计算机联锁系统与站各种电路结合说明。 (23) （一）、64D半自动闭塞 (23) （二）、四线制自动闭塞 (26) （三）、场间联系 (29) （四）、站间联系 (31) （五）、道口通知 (33) （六）、机务段联系 (35) （七）、推峰进路 (37) （八）、编发线与驼峰照查电路 (39)
（九）、非进路调车 (40) （十）、溜放 (41) （十一）、坡道延续进路 (42) （十二）、到发线出岔 (42) （十三）、局控道岔 (42) （十四）、跨场进路 (43) （十五）、与编组场衔接道岔照查电路 (45) 一、总则 为适应铁路运输生产安全的需要，提高计算机联锁厂家与沟通、配合的效率，并减少因沟通不充分而产生的人为错误，因此，需要统一计算机联锁系统接口设计标准。 本规适用于与继电电路结合的计算机联锁系统的接口设计，不适用于全电子联锁系统。 由于不同的联锁厂家对各自联锁系统会有一些特殊要求，所以本规中所列举的采集、驱动信息可能不能做到全部体现，故还需与相应联锁厂家进行必要的沟通。 不同型号的联锁系统与站各种电路结合时，对继电器的驱动时机可能会有不同，本规中所述为铁科院联锁系统的情况，其他联锁系统的具体情况还需与相应联锁厂家沟通。
附件4：数据交换接口规范 一、概述 计量器具检定数据交换接口采用Web service作为数据传输机制，是自包含、自描述（WSDL）、模块化的应用，由省局发布、定位、各技术机构通过web方式调用。接口基于标准的互联网协议，支持超文本传输协议(HTTP)和XML。与省局交换的数据都封装成XML格式的文件，传输前以GZIP格式将文件压缩，然后设置BASE64编码，最后在接收端将其解压，解析读取数据。 二、软件准备 JDK1.6，tomcat6.0，Web service相关包以及数据库。三、数据交换示意图 四、服务端接收数据过程 1、用户合法性校验：服务端在接收数据时同样需要进行用户合法性 校验，并返回信息。
2、数据封装：为方便数据传输和解析，客户端通过Web service交 换的数据需要封装成可扩展标记语言XML的规范，并严格按照此规范。 3、数据压缩：为提高数据的传输效率和减小传输的数据量，客户端 在传输之前需将数据以GZIP格式进行压缩，并设置BASE64位编码，以便基于HTTP传输。 4、对上传文件进行规范性校验：服务端在接收数据之前，校验客户 端数据是否按照XML规范要求，并按GZIP格式进行压缩，设置BASE64编码，否则返回不合法文件格式。 5、返回结果：服务端进行完校验，解析成功并反馈给业务系统后， 会反馈成功信息给客户端，如不成功则返回不成功。 五、客户端接收数据过程（与服务端接收过程类似。） 六、术语说明
THANKS !!! 致力为企业和个人提供合同协议，策划案计划书，学习课件等等 打造全网一站式需求 欢迎您的下载，资料仅供参考
软件设计文档国家标准GB8567-88 一、文档编写标准化 在整个项目开发及使用过程中，应该有完备的文档支持，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性和可追溯性。 完备的文档对软件的开发及使用起了很大的作用。一般要求编写好十三种文档。 1、可行性分析报告 说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 2、项目开发计划 为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 3、软件需求说明书（软件规格说明书） 对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 4、概要设计说明书 是概要设计阶段的工作总结。主要包括功能分配、模块划分、程序总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理等，为详细设计作好准备。 5、详细设计说明书 着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 6、用户操作手册 详细描述了该软件的功能、性能和用户界面，使用该软件的具体方法等。 7、测试计划 包括测试内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。8、测试分析报告 测试计划的执行情况，对测试结果的分析，提出测试结论。 9、开发进度月报 按月提交的项目进展情况报告。包括计划与实际执行情况的对比、阶段成果、遇到的问题、解决的方法以及下一步的打算。 10、项目开发总结报告 项目完成以后，总结实际执行情况。如进度、成果、资源利用、成本和投入的人力，对项目开发作出评价，总结经验与教训。 11、软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件说明、维护过程说明等。12、软件问题报告 记录软件出现问题的日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。13、软件修改报告 软件产品投入使用后，发现了需修改、更正的问题，要将出现的问题、修改意见、修改可能出现影响作出详细描述，提交审批。 二、可行性分析报告的撰写要求 可行性研究报告的编写内容要求如下： 1 引言
软件结构设计规范
精选编制： 审核： 批准：
目录 1.简介 (6) 1.1.系统简介 (6) 1.2.文档目的 (6) 1.3.范围 (6) 1.4.与其它开发任务/文档的关系 (6) 1.5.术语和缩写词 (6) 2.参考文档 (8) 3.系统概述 (9) 3.1.功能概述 (9) 3.2.运行环境 (9) 4.总体设计 (10) 4.1.设计原则/策略 (10) 4.2.结构设计 (10) 4.3.处理流程 (10) 4.4.功能分配与软件模块识别 (11) 5.COTS及既有软件的使用 (12) 5.1.COTS软件的识别 (12) 5.2.COTS软件的功能 (12)
5.3.COTS软件的安全性 (12) 5.4.既有软件的识别 (12) 5.5.既有软件的功能 (13) 5.6.既有软件的安全性 (13) 6.可追溯性分析 (14) 7.接口设计 (15) 7.1.外部接口 (15) 7.2.内部接口 (15) 8.软件设计技术 (16) 8.1.软件模块 (16) 8.2.数据结构 (16) 8.3.数据结构与模块的关系 (16) 9.软件故障自检 (17)
1.简介 1.1.系统简介 提示：对系统进行简要介绍，包括系统的安全目标等。 1.2.文档目的 提示： 软件结构设计的目的是在软件需求基础上，设计出软件的总体结构框架，实现软件模块划分、各模块之间的接口设计、用户界面设计、数据库设计等等，为软件的详细设计提供基础。 软件结构设计文件应能回答下列问题： 软件框架如何实现软件需求； 软件框架如何实现软件安全完整度需求； 软件框架如何实现系统结构设计； 软件框架如何处理与系统安全相关的对软/硬件交互。 1.3.范围 1.4.与其它开发任务/文档的关系 提示：如软件需求和界面设计文档的关系 1.5.术语和缩写词 提示：列出项目文档的专用术语和缩写词。以便阅读时，使读者明确，从
监管报表数据报送接口规范修订历史纪录
一、销售机构、基金资金划付明细文件格式建议（J01） （一）报表格式 使用标准txt文件，文件内容格式如下(左侧数字表示行号)： 1.总记录数（不包括本行） 2.交易确认日期(YYYYMMDD)|交易申请日期(YYYYMMDD)|基金代 码|业务类型编码|销售机构向基金划付金额|基金向销售机构划付金额|登记结算机构代码| 3.交易确认日期(YYYYMMDD)|交易申请日期(YYYYMMDD)|基金代 码|业务类型编码|销售机构向基金划付金额|基金向销售机构划付金额|登记结算机构代码| （二）报表说明 用于表示基金销售机构与基金之间的实际资金划付。其中资金划付日期是指实际资金汇划的日期；交易确认日期是与指该笔资金划付相对应的基金交易的确认日期；交易申请日期是与指该笔资金划付相对应的基金交易的申报日期；业务类型是指基金交易业务代码，包括：认购（一次交易确认为120、二次交易确认为130）、申购122、定额申购139、赎回124、定额赎回163、强制赎回142、分红143。 对于三种特殊业务类型“交易申请日期”字段的说明。分红143业务：“交易申请日期”填写权益登记日；强制赎回142业务：“交易申请日期”填写交易确认日期的上一工作日（由于上工作日的赎回可能会和当日的强赎合并划款）；认购退款130业务：“交易申请日期”填写交易确认日期。 报送的实际资金划付数据是按照基金代码、业务类型进行
汇总的，即对于某个具体的资金划付日期，针对一只基金的某种业务类型，只申报一条汇总数据记录。 对于一种业务类型而言，只存在销售机构向基金划付金额或者只存在基金向销售机构划付金额。 基金代码---目前为6位编码，最长可扩展至30位。 业务类型---目前为3位编码，最长可扩展至30位。 登记结算机构代码--目前为8位编码，最长可扩展至30位。 （三）核对逻辑 中国结算每日将基金确认成功的交易数据按照基金代码、销售机构代码、业务类型进行汇总统计，得出销售机构各业务对基金应划入金额和应划出金额，用于与J01报表中的实际划付金额数据进行核对。中国结算汇总统计基金划入和基金划出金额的方法是：对认购业务，第一次确认（业务类型120）时统计的基金应收金额为：汇总每笔交易的确认金额全额；第二次确认（业务类型130）时统计的基金应付金额为：汇总每笔交易的（一次确认金额-二次确认金额+退回给投资人的利息）。 对申购（业务类型122）和定额申购（业务类型139）业务，统计的基金应收金额为：汇总每笔交易的（确认金额全额-代理费）。 对赎回（业务类型124）、定额赎回（业务类型163）、强制赎回（业务类型142）业务，统计的基金应付金额为：汇总每笔交易的（投资人实得金额+代理费）。 对分红（业务类型143）业务，统计的基金应付金额为：汇总每笔交易的（投资人实得现金红利金额）。
目录 1 接口类型 (2) 1.1 人机接口 (2) 1.2 软件-硬件接口 (2) 1.3 软件接口 (2) 1.4 通信接口 (2) 2 接口设计规范 (2) 2.1 基本内容 (2) 2.2 规格说明 (3) 2.2.1 人机接口 (3) 2.2.2 软件-硬件接口 (3) 2.2.3 软件接口 (3) 2.2.4 通信接口 (3) 3 接口设计文档提纲 (3)
1接口类型 1.1人机接口 人机接口是指计算机系统为完成人与机器之间互相传送信息而提供的功能的接口，包括硬件及程序。 1.2软件-硬件接口 软件-硬件接口是指软件系统中软件与硬件之间的接口。例如软件与接口设备之间的接口。 1.3软件接口 软件接口是软件系统中程序之间的接口。包括软件系统与其他系统或子系统之间的接口、程序模块之间的接口、程序单元之间的接口等。 1.4通信接口 通信接口是指处理机和标准通信子系统之间的接口。包括为实现数据通信用来完成接口功能的部件、装置及有关软件。 2接口设计规范 2.1基本内容 1、接口的名称标识 2、接口在该软件系统中的地位和作用 3、接口在该软件系统中与其他程序模块和接口之间的关系
4、接口的功能定义 5、接口的规格和技术要求，包括它们各自适用的标准、协议或约定 6、各个接口的数据特性 7、各个接口的资源要求，包括硬件支持、存储资源分配等 8、接口程序的数据处理要求 9、接口的特殊设计要求 10、接口对程序编制的要求 2.2规格说明 2.2.1人机接口 准确地说明人机接口的设计条件、设计特征、编程要求等技术内容。包括人机交互环境、人机接口部件、信息传输方式及传输特性、信息格式、数据处理、存储资源分配和程序编制要求等。 2.2.2软件-硬件接口 逐个描述每一个软件-硬件间接口的设计特性。包括接口硬件说明、接口功能说明、接口信息说明、接口处理方法、接口控制方式、接口时间特性、存储资源分配和程序编制要求等。 2.2.3软件接口 逐个说明本软件系统与其他软件系统间接口的设计特征。包括接口功能说明、接口约定、数据特性、数据处理方法、接口程序运行控制、接口时间特性、存储资源分配和程序编制要求等。 2.2.4通信接口 逐个描述各个通信接口的设计特性。包括硬件描述、接口功能说明、通信协议、报文处理、存储资源分配、程序接口设计和程序编制要求等。 3接口设计文档提纲 1 概述 (2) 1.1 编写目的 (2) 1.2 参考资料 (2)
Q/DKBA 深圳市华为技术有限公司技术规范 错误！未定义书签。Q/DKBA0.200.035-2000 逻辑电平接口设计规范
2000-06-20发布 2000-06-20实施深圳市华为技术有限公司发布
本规范起草单位：各业务部、研究技术管理处硬件工程室。 本规范主要起草人如下：赵光耀、钱民、蔡常天、容庆安、朱志明，方光祥、王云飞。 在规范的起草过程中，李东原、陈卫中、梅泽良、邢小昱、李德、梁军、何其慧、甘云慧等提出了很好的建议。在此，表示感谢！ 本规范批准人：周代琪 本规范解释权属于华为技术有限公司研究技术管理处硬件工程室。 本规范修改记录：
目录 1、目的 5 2、范围 5 3、名词定义 5 4、引用标准和参考资料 6 5、TTL器件和CMOS器件的逻辑电平8 5.1：逻辑电平的一些概念8 5.2：常用的逻辑电平9 5.3：TTL和CMOS器件的原理和输入输出特 性9 5.4：TTL和CMOS的逻辑电平关系10 6、TTL和CMOS逻辑器件12 6.1：TTL和CMOS器件的功能分类12 6.2：TTL和MOS逻辑器件的工艺分类特点13 6.3：TTL和CMOS逻辑器件的电平分类特点13 6.4：包含特殊功能的逻辑器件14 6.5：TTL和CMOS逻辑器件的选择15 6.6：逻辑器件的使用指南15 7、TTL、CMOS器件的互连17 7.1：器件的互连总则17 7.2：5V TTL门作驱动源20 7.3：3.3V TTL/CMOS门作驱动源20 7.4：5V CMOS门作驱动源20 7.5：2.5V CMOS逻辑电平的互连20 8、EPLD和FPGA器件的逻辑电平21 8.1：概述21 8.2：各类可编程器件接口电平要求21 8.3：各类可编程器件接口电平要求21 8.3.1：EPLD/CPLD的接口电平21 8.3.2：FPGA接口电平25 9、ECL器件的原理和特点35 9.1：ECL器件的原理35 9.2：ECL电路的特性36 9.3：PECL/LVPECL器件的原理和特点37 9.4：ECL器件的互连38 9.4.1：ECL器件和TTL器件的互连38 9.4.2：ECL器件和其他器件的互连39 9.5：ECL器件的匹配方式39 9.6：ECL器件的使用举例41 9.6.1：SYS100E111的设计41 9.6.2：SY100E57的设计42 9.1：ECL电路的器件选择43 9.2：ECL器件的使用原则43
中国财务软件数据接口标准(DOC7) 编者按:标准应该是衡量事务的准则。标准的制定一样都由国际/国家有关标准机构或行业主管部门完成。但一些行业的生产厂商为了爱护用户的投资,促进行业有序进展,也按照本行业的特点,联合起来制定了一些大伙儿认可并共同遵守的规范,这种做法在国外已被广泛采纳。随着中国改革开放的深入,国内一些行业的厂家也开始进行这方面的探究,本期我们刊登的《中国财务软件数据接口标准》确实是由该财务软件行业的民间组织——中国软件行业协会财务及企业治理软件分会制定的,起草者为闻名财务软件厂商深圳金蝶公司。 一、背景 目前,国内财务软件众多,它们采纳的数据库平台和数据库结构各不相同,不同财务软件之间的数据交换,因为数据库平台和结构不同而产生许多困难,几乎任意两个不同软件之间要实现数据传递都会存在专门的数据转换咨询题。烦琐的数据转换工作白费了大量人力和物力,同时也阻碍了财务软件产业的健康进展。国内财务软件的商业化差不多比较成熟,各财务软件公司都有一批用户。由于各种缘故,一些用户期望从一个软件交叉升级为另一软件。由于用户在旧软件上已做了大量的工作,必定期望升级后原有数据能移植到新的软件中,然而有些软件的数据文件通过加密或数据库结构未公布,要从中直截了当读取数据几乎不可能。为了爱护用户已付出的劳动,各财务软件需要提供一个标准的数据输入输出接口。如此,建立一个公用的数据交换标准是专门必要的。 用户在使用财务软件时,有一些需求通过财务软件本身是难以实现的,如:用户期望把会计报表通过电子表格软件处理输出为各种专门形式;另一些高级用户,则期望在其它治理软件中能取到财务数据。这些数据交换工作都需要有一个标准的数据接口来规范。财务会计通过长期的进展已形成一定的理论,财务会计工作也有规范可循,国内财务软件是在这些理论和规范的基础上开发出来的,各软件储存财务数据的模式也大同小异。财务数据要紧按会计科目、凭证、余额及发生额、报表几个部分分块储备,它们之间既
服务端与手机平台 接口协议 BespRout 2014年11月
文档修改/审批记录
目录 1.概述 (4) 2.涉及接口 (4) 3.接口总体要求 (4) 3.1.系统间接口的原则 (4) 3.2.处理流程 (4) 3.3.接口实现方式 (5) 4.XXX服务端接口 (5) 4.1.XX模块-根据XX下载相关的配置文件 (5) 4.2.XX模块-生成指定XX的文件配置 (6) 4.3.APP启动-初使化参数 (7) 5.附件 (8) 5.1.备注说明 (8)
1. 概述 本文档提供接口给手机端使用，为手机端提供业务平台数据 2. 涉及接口 本文档涉及的外围系统接口包括：无 3. 接口总体要求 3.1.系统间接口的原则 接口设计遵循如下原则： ?安全可靠性原则：系统应提供良好的安全性和可靠性策略，支持多种安全而 可靠的技术手段，制定严格的安全可靠的管理措施； ?开放性原则：提供开放式标准接口，提供与其它系统的互联互通； ?灵活性原则：提供灵活的接口设计，便于接口的变动。 ?可扩展性原则：支持新业务的扩展以及接口容量与接口性能的提高； ?可管理性原则：提供良好的管理机制，保证在运行过程中提供给管理员方便 的管理方式以处理各种情况； ?统一性原则：应当保证系统的接口方式、接口形式、使用的协议等标准、统 一。 3.2.处理流程 接口处理流程
3.3. 接口实现方式 手机APP 应用 与服务端采用基于HTTP 的REST 协议完成，数据传输默认为JSON 4. XXX 服务端接口 测试地址前缀: http://192.168.3.208:8088/xxx/xxx 4.1. XX 模块-根据XX 下载相关的配置文件
中国结算开放式基金新版系统管理人数据接口规范(TXT) 版本1.1 二○○九年九月
1. 总则 (4) 2. 术语定义 (4) 3. 基本要求 (8) 4. 数据接口 (10) 4.1. 信息格式 (10) 4.2. 接口文件名定义 (11) 4.3. TA支持业务 (13) 4.4. 业务数据项 (15) 4.4.1. 开户确认业务101 (16) 4.4.2. 销户确认业务102 (20) 4.4.3. 客户资料修改确认业务103 (21) 4.4.4. 撤销交易账号确认109 (25) 4.4.5. 变更交易帐户确认158 (27) 4.4.6. 认购业务数据项020 (27) 4.4.7. 认购结果业务数据项057 (29) 4.4.8. 申购业务数据项022 (31) 4.4.9. 定期定额申购业务数据项039 (34) 4.4.10. ETF一次申购业务数据项091 (37) 4.4.11. ETF二次申购业务数据项092 (39) 4.4.12. 赎回业务数据项024/定期定额赎回业务数据项063 (42) 4.4.13. ETF一次赎回业务数据项093 (46) 4.4.14. ETF二次赎回业务数据项094 (48) 4.4.15. 预约赎回业务数据项025 (51) 4.4.16. 撤预约单业务数据项053 (53) 4.4.17. 转托管业务数据项026/028 (55) 4.4.18. 转托管入业务数据项027 (56) 4.4.19. 设置分红方式业务数据项029 (58) 4.4.20. 基金转换业务数据项036 (59) 4.4.21. 份额冻结业务数据项031 (62) 4.4.22. 份额解冻业务数据项032 (64) 4.4.23. 非交易过户业务数据项033 (65) 4.4.24. 强增业务数据项044 (67) 4.4.25. 强减业务数据项045 (68) 4.4.26. 开通定期定额协议业务数据项059 (70) 4.4.27. 撤销定期定额协议业务数据项060 (71) 4.4.28. 变更定期定额协议业务数据项061 (72) 4.4.29. 认购业务数据项120 (74) 4.4.30. 认购结果业务数据项130 (75) 4.4.31. 申购业务数据项122 (78) 4.4.32. 定期定额申购业务数据项139 (81) 4.4.33. ETF一次申购业务数据项191 (83) 4.4.34. ETF二次申购业务数据项192 (85) 4.4.35. 赎回业务数据项124/定时定额赎回163 (88) 4.4.36. 强制赎回业务数据项142 (91)
最近一段时间一直在做APP接口，总结一下APP接口开发过程中的注意事项： 1、效率：接口访问速度 APP有别于WEB服务，对服务器端要求是比较严格的，在移动端有限的带宽条件下，要求接 口响应速度要快，所有在开发过程中尽量选择效率高的框架，PHP建议使用YAF框架。 2、数据格式 最好使用JSON格式数据，因为JSON有较好的跨平台性。对于 3、数据量 按需分配，APP客户端需要什么数据就返回什么数据，过多的数据量影响处理速度，最重要的 是影响传输效率。 4、接口、参数命名准确 无论是接口还是参数，命名都应该有意义，让人一目了然。 5、一个页面尽可能就用一个接口 现在很多的APP页面都有广告、焦点图、文章列表等，对于这些不同格式的数据，不可能都分 配一个接口，这样加大了APP请求接口数，影响响应速度。建议服务器端尽可能处理好数据后 通过一个接口返回给APP客户端。 6、缓存 这点比较重要，不管是文件缓存还是memcache缓存。 7、接口要有可扩展性 8、接口安全 目前一般都是在APP客户端和服务器通过约定的算法，对传递的参数值进行验证匹配。但是如 果APP程序被反编译，这些约定的算法就会暴露，特别是在安卓APP中，有了算法，完全就 可以通过验证模拟接口请求。 9、接口版本控制 对于接口版本控制，自己目前也没有找到一个好的方法，怎么去应对不断的APP版本升级，新、旧接口的处理。 10、接口数据、状态 接口必须提供明确的数据状态信息，不管是成功的，还是失败的，都必须返回给APP客户端。 以上10点就是自己在这端时间做APP接口过程中注意的事项，写的有点乱，想到什么就写什么。
1 前言 《企业信用信息基础数据库数据接口规》（简称“数据接口规”）规定了企业信用信息基础数据库与外部系统进行信息交换时应遵循的有关信息格式和数据管理规定，本文档分为六部分。 前言简介本规各部分的容。 报文规规定了本规中报文的基本概念、设计原则、数据处理原则、文件命名原则、报文文件的结构和种类。 数据采集要求规定了公积金管理中心提交数据的围、频率以及文件传送方式。 公积金信息采集报文和公积金信息删除报文中规定了公积金中心向企业信用信息基础数据库报送采集报文和删除报文的具体数据项以及对数据项的描述和约束。 公积金信息反馈报文规定了企业信用信息基础数据库向公积金中心反馈容的具体数据项以及对数据项的描述和约束。 附录包含公积金信息采集接口规的代码表、数据校验规则。 本接口规适用于与企业信用信息基础数据库进行报文交换的公积金机构及公积金部门的数据处理。文档的主要读者有：拟建系统用户、系统设计人员、系统编码人员、项目经理、系统测试人员、项目监理人员。 2 报文规 2.1术语和定义 下列术语和定义适用于本规。 2.1.1报文 由报文头、报文体构成的，按照一定规则组合起来的数据集合体。 2.1.2报文文件 包含报文的数据文件。 本规中报文文件与报文是一对一的关系。 2.1.3段 一个已标识、命名和结构化的、在功能上相互关联的复合数据元和/或独立数据元的集合。段有各自固定的长度。 本规中段为基础段。 2.1.4信息记录 数据采集的基本信息单位，包含报送机构一笔业务的有关数据。 本规中的信息记录由基础段组成。 2.1.5报文头 每个报文必须包含且只包含一个报文头，报文头表示一次数据采集的开始，该部分给出本次采集数据的信息提要。 2.1.6报文体 报文体是数据采集报文的主体容，报文体部分可包含一种或多种不同类型的信息记录，最后一条信息记录结束即为报文结束。 信息记录之间用一个回车换行符（“﹨r﹨n”或“﹨n”）分隔。 2.1.7信息记录 此信息记录由基础段组成。 每个信息记录包含且仅包含一个基础段。 信息记录的容中不允许存在回车换行符（“﹨r﹨n”或“﹨n”）。 2.1.8基础段 基础段是由固定数据项按照一定次序排列组成的信息集合体。 2.2设计原则
软件设计规范 概述 软件设计是把需求转化为软件系统的最重要的环节，系统设计的优劣在根本上决定了软 件系统的质量。 在此，主要阐述软件系统设计的5个核心内容：体系结构设计、用户界面设计、数据库设计、模块设计、数据结构和算法设计。旨在帮助开发人员搞清楚“设计什么”以及“如何 设计”。 一般把设计过程划分为两个阶段：概要设计阶段和详细设计阶段，如下所示： *概要设计阶段的重点是体系结构设计。 *详细设计阶段的重点是用户界面设计、数据库设计、模块设计、数据结构与算法设计 等。 可根据项目的情况进行文档裁减和过程合并，如项目开发过程只有一个设计阶段和设计 文档。 体系结构 体系结构如同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容，这家 伙始终都是猴子，不会成为人。 由此可见，体系结构乃是系统设计的重中之重。 目前业界比较流行的软件结构模式有C/S（客户/服务器）、B/S（BROWSE/SERVER）、层次结构（上下级层次结构、顺序相邻的层次结构、含中间件的层次结构） 体系结构设计原则 ● 合适性 即体系结构是否适合于软件的“功能性需求”和“非功能性需求”。高水平的设计师高就高在“设计出恰好满足客户需求的软件，并且使开发方和客户方获取最大的利益，而不是 不惜代价设计出最先进的软件。 ● 结构稳定性 详细设计阶段的工作如用户界面设计、数据库设计、模块设计、数据结构与算法设计等等，都是在体系结构确定之后开展的，而编程和测试则是更后面的工作，因此体系结构应在 一定的时间内保持稳定。
软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。人们希望在需求发生变化时，最好只对软件做些皮皮毛毛的修改，可千万别改动软件的体系结构。如果当需求发生变化时，程序员不得不去修改软件的体系结构，那么这个软件的系统设计是失 败的。 高水平的设计师应当能够分析需求文档，判断出哪些需求是稳定不变的，哪些需求是可能变动的。于是根据那些稳定不变的需求设计体系结构，而根据那些可变的需求设计软件的 “可扩展性”。 ● 可扩展性 可扩展性是指软件扩展新功能的容易程度。可扩展性越好，表示软件适应“变化”的能 力越强。 可扩展性越来越重要，这是由现代软件的商业模式决定的： *社会的商业越发达，需求变化就越快。需求变化必将导致修改（或者扩展）软件的功能，现代软件的规模和复杂性要比十年前的大得多（对比一下操作系统的变化就明白了），如果软件的可扩展性比较差的话，那么修改（或者扩展）功能的代价会很高。 *现代软件产品通常采用“增量开发模式”，开发商不断地推出软件产品的新版本，从而不断地获取增值利润。如果软件的可扩展性比较差的话，每次开发新版本的代价就会很高。虽然开发商抓住了商机，但却由于设计水平差而导致没有赚取多少利润，真是要活活气死。 ● 可复用性 由经验可知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大量成熟的工作可以通过 复用来快速实现（即具有高生产率）。 可复用性是设计出来的，而不是偶然碰到的。要使体系结构具有良好的可复用性，设计师应当分析应用域的共性问题，然后设计出一种通用的体系结构模式，这样的体系结构才可 以被复用。 用户界面设计 为了提高用户界面的易用性和美观程度，总结了十个设计原则。用于提高易用性的界面 设计原则有8个： *用户界面适合于软件的功能 *容易理解 *风格一致
HIS医保接口设计规范 一、导言 BSHIS在两年前就开始涉及医保软件接口的设计和实施了。随着时间的推移，越来越多的新签医院工程也要求实施医保；而一些以前上的老工程，也开始在实施各地的医保政策。可以说，医保的实施已经成为HIS软件在医院实施中一个很重要的组成部分。从某种意义上讲，医保实施的好坏也已经直接影响了工程实施的进度和效果。 由于医保政策的复杂性，再加上政策有很大的地区差异。在实施过程中，软件设计人员遇到了很多比较复杂也或者很难于解决的问题。另外，由于医保政策一般都是刚刚指定出来不久的。所以，在实施的过程中，经常会遇到修改政策的过程。这在一定程度上给软件设计和实施增加了不少的难度。同时，也会导致医保接口软件设计上的不确定性，直接的后果是可能导致很多的重复劳动。 结合前面很多人医保实施成功和失败的教训，对在医保接口设计过程中的，好的方法进行了归纳，并尽量给出一种比较完善和完美的设计解决方法和规范，可帮助医保实施和软件接口设计人员比较好地实施医保。当然，现在只是个草稿，需要医保实施实践不断地扩充此规范，以至形成一种比较固定的综合解决方案。 二、关于医保政策软件和应对方案 我们通过对北京安宁盈科、创智公司、东大阿儿派、杭州新世纪、建达电子、万达公司等各个医保险政策软件提供商提供的接口方案进行了分析，总计出他们之间的共性如下： 1、一般都提供DOS和WINDOWS两套方案，DOS下一般用文件形式传递 数据，WINDOWS下一般以WIN32 API的形式在HIS和医保前置机之间 调用和传递数据（DLL提供了政策函数）。我们以后者为重点说明问题。 2、政策函数一般分为两类：单个函数和多个函数两种类型设计 多个函数是指每中业务或者比较相似的业务为一个函数，这样组成结算、登记、退费等多个函数。如：杭州新世纪、东大阿儿派 单个函数是指所有的业务都用一个函数实现。参数一般用结构字符串实现。 如：上海万达公司。 3、明细数据一般都和结算时必要的项目数据分开传递到医保中心服务器。 这样做的目的是为了减少网络阻塞。如果是同时要传的，一般在结算准 备阶段就已经将数据计算好了。 4、平时发生费用时，一般分成两种方式处理： 1）平时的自负比例按HIS中设置的算，也不需要审批
软件界面设计规范 1.界面规范 .总体原则以用户为中心。 设计由用户控制的界面，而不是界面控制用户。清楚一致的设计。所有界面的风格保持一致，所有具有相同含义的术语保持一致，且易于理解拥有良好的直觉特征。以用户所熟悉的现实世界事务的抽象来给用户暗示和隐喻，来帮助用户能迅速学会软件的使用。较快的响应速度。简单且美观。 .原则详述 1.2.1.用户控制用户界面设计的一个重要原则是用户应该总是感觉在控制软件而不是感觉被软件所控制。操作上假设是用户--而不是计算机或软件--开始动作。用户扮演主动角色，而不是扮演被动角色。在需要自动执行任务时，要以允许用户进行选择或控制它的方式来实现该自动任务。提供用户自定义设置。因为用户的技能和喜好各不相同，因此他们必须能够个性化界面的某些方面。Windows为用户提供了对许多这方面的访问。您的软件应该反应不同的系统属性--例如颜色、字体或其他选项的用户设置。采取交互式和易于感应的窗口，尽量避免使用模态对话框，而使用"非模式"辅助窗口。"模式"是一种状态，它排除一般的交互，或者限制用户只能进行特定的交互。当最好使用一个模式或该模式只是可替换的设计时--例如，用于在一个绘图程序中选定一个特定感觉--请确保该模式是显然的、可见的，是一个明确的用户选定的结果，并且容易取消。在后台运行长进程时，保持前台式交互。例如，当正在打印一个文档，即使该文档不能被改变，用户也应该可以最小化该窗口。谅解。用户喜欢探索一个界面，并经常从尝试和错误中学习。一个有效的界面允许交互式的发现，它只提供一组合适的选择，并在用户可能破坏系统或数据的情况时发出警告。如果可行，还应提供可逆转或可还原的操作。即使在设计得很好得界面中，用户也可能犯错误。这些错误既可以是物理上得（偶然地指向了错误的命令或数据），也可以是逻辑上的（对选定哪一个命令或哪些数据做出了错误的决定）。有效的设计避免很可能导致错误的情况。它还包容潜在的用户错误，并且使用户易于还原。 1.2.2.清楚一致的设计一致允许用户将已有的知识传递到新的任务中，更快地学习新事物，并将更多的注意力集中在任务上。这是因为他们不必花时间来尝
接口设计规范 Prepared on 24 November 2020
目录 1接口类型 1.1人机接口 人机接口是指计算机系统为完成人与机器之间互相传送信息而提供的功能的接口，包括硬件及程序。 1.2软件-硬件接口 软件-硬件接口是指软件系统中软件与硬件之间的接口。例如软件与接口设备之间的接口。 1.3软件接口 软件接口是软件系统中程序之间的接口。包括软件系统与其他系统或子系统之间的接口、程序模块之间的接口、程序单元之间的接口等。 1.4通信接口 通信接口是指处理机和标准通信子系统之间的接口。包括为实现数据通信用来完成接口功能的部件、装置及有关软件。
2接口设计规范 2.1基本内容 1、接口的名称标识 2、接口在该软件系统中的地位和作用 3、接口在该软件系统中与其他程序模块和接口之间的关系 4、接口的功能定义 5、接口的规格和技术要求，包括它们各自适用的标准、协议或约定 6、各个接口的数据特性 7、各个接口的资源要求，包括硬件支持、存储资源分配等 8、接口程序的数据处理要求 9、接口的特殊设计要求 10、接口对程序编制的要求 2.2规格说明 2.2.1人机接口 准确地说明人机接口的设计条件、设计特征、编程要求等技术内容。包括人机交互环境、人机接口部件、信息传输方式及传输特性、信息格式、数据处理、存储资源分配和程序编制要求等。 2.2.2软件-硬件接口 逐个描述每一个软件-硬件间接口的设计特性。包括接口硬件说明、接口功能说明、接口信息说明、接口处理方法、接口控制方式、接口时间特性、存储资源分配和程序编制要求等。 2.2.3软件接口 逐个说明本软件系统与其他软件系统间接口的设计特征。包括接口功能说明、接口约定、数据特性、数据处理方法、接口程序运行控制、接口时间特性、存储资源分配和程序编制要求等。
计算机联锁接口设计规范 编写— 审核—___________ 版本—___________ 日期—____年___月___日
历史记录
一、总则 (4) 二、采集、驱动信息说明 (5) (一)、基本采集信息： (5) (二)、特殊采集信息： (8) (三)、基本驱动信息： (10) (四)、防护用特殊驱动信息： (12) 三、设计院需告知的内容说明 (14) (一)、轨道停电 (14) (二)、引导总锁闭 (14) (三)、发车方向继电器 (14) (四)、接近延长 (14) (五)、点灯电路 (15) 四、计算机联锁系统与站内各种电路结合说明。 (17) （一）、64D半自动闭塞 (17) （二）、四线制自动闭塞 (19) （三）、场间联系 (21) （四）、站间联系 (22) （五）、道口通知 (24) （六）、机务段联系 (25) （七）、推峰进路 (27) （八）、编发线与驼峰照查电路 (29) （九）、非进路调车 (29) （十）、溜放 (30) （十一）、坡道延续进路 (30) （十二）、到发线出岔 (31) （十三）、局控道岔 (31) （十四）、跨场进路 (32) （十五）、与编组场衔接道岔照查电路 (33)
一、总则 为适应铁路运输生产安全的需要，提高计算机联锁厂家与设计院沟通、配合的效率，并减少因沟通不充分而产生的人为错误，因此，需要统一计算机联锁系统接口设计标准。 本规范适用于与继电电路结合的计算机联锁系统的接口设计，不适用于全电子联锁系统。 由于不同的联锁厂家对各自联锁系统会有一些特殊要求，所以本规范中所列举的采集、驱动信息可能不能做到全部体现，故还需设计院与相应联锁厂家进行必要的沟通。 不同型号的联锁系统与站内各种电路结合时，对继电器的驱动时机可能会有不同，本规范中所述为铁科院联锁系统的情况，其他联锁系统的具体情况还需设计院与相应联锁厂家沟通。 本规范分为以下几个具体部分： （一）、采集、驱动信息说明； （二）、设计院需告知的内容说明； （三）、计算机联锁系统与站内各种电路结合说明。