北斗卫星导航系统用户终端通用数据接口（预）
目录
1 范围 (2)
2 规范性引用文件 (2)
3 要求 (2)
3.1 硬件 (2)
3.1.1 概述 (2)
3.1.2 互连线 (2)
3.1.3 连接器 (3)
3.1.4 发送器和接收器 (3)
3.2 数据传送 (3)
3.3 数据格式协议 (3)
3.3.1 字符 (3)
3.3.2 字段 (5)
3.3.3 语句 (13)
3.3.4 错误检测和处理 (16)
3.4 数据内容 (17)
3.4.1 字符定义 (17)
3.4.2 RNSS语句格式 (17)
3.4.3 RDSS语句格式 (45)
3.4.4 专用语句 (61)
3.4.5 特殊语句格式 (72)
1 范围
本要求规定了北斗卫星导航系统与终端之间的数据接口相关要求。
本要求适用于北斗卫星导航系统与应用研究。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T 6107—2000 使用串行二进制数据交换的数据终端设备和数据电路终接设备之间的接口
GB/T 11014—1989 平衡电压数字接口电路的电气特性
3 要求
3.1 硬件
3.1.1 概述
北斗终端应可以通过一根连接线缆并入连接多个接收器。接收器的数目取决于发送器的输出驱动能力、终端的输入驱动要求和是否使用终端电阻器。
3.1.2 互连线
互连线可以通过一根屏蔽双绞线外加一根使装置共地的接地保护线互连。应对屏蔽双绞线增加一根单线使装置共地的接地保护连线。应对屏蔽双绞线增加一根单线或利用双层屏蔽绝缘电缆线的内绝缘层。
3.1.3 连接器
终端中尽量选用通用连接器。
3.1.4 发送器和接收器
发送器和接收器电信号特性应符合GB/T 6107—2000中第2章和GB/T 11014—1989中第4章的要求。
3.2 数据传送
数据以串行异步方式传送。第一位为起始位，其后是数据位。数据遵循最低有效位优先的规则。所用参数如下：
?波特率：4800～115200 bps，可根据需要设定，默认值为115200 bps；
?数据位：8 bit（d7=0）；
?停止位：1 bit；
?校验：无。
3.3 数据格式协议
3.3.1 字符
3.3.1.1 预留字符
预留字符集由表1所示的ASCII字符组成。这些字符用于语句和字段定界，不应把它们用在数据段中。
表1 预留字符
3.3.1.2 有效字符
有效字符集包括所有可印刷的ASCII字符（HEX20到HEX7F），但定义为预留字符者除外。
3.3.1.3 非定义字符
没有定义成“预留字符”和“有效字符”的ASCII字符，任何时候都不应该发送。
3.3.1.4 字符符号
当用个别字符定义测量单位、说明数据字段类型和语句类型等内容时，应依据注释解释这些字符。
3.3.2 字段
字段由位于两个适当的定界字符之间的一串有效字符，或是没有字符（空字段）组成。
3.3.2.1 地址段
3.3.2.1.1 概述
地址段是一条语句中的第一个字段，它跟在定界符“$”或“！”之后，用于定义该语句。定界符“＄”用于识别符合常规参数和定界字段组成规则的语句，“！”用于识别符合专用压缩和非定界字段组成的规则的语句。地址字段中的字符限于数字和大写字母。地址段不应是空字段。带有地址字段和询问地址段这两种地址字段的语句才能被传送。
3.3.2.1.2 地址字段
地址字段由5个数字或大写字母组成。前面两个字符为发送器的标识符助记码，见表2。
表2 发送器标识符助记码
发送器标识符用于定义所传输数据的特性，对于能传输多个来源数据的装置应当传送适当的标识符。
地址字段的后三个标识符为通用语句标识符，用于定义传输数据的格式和类型，见表3。
表3 通用语句标识符
3.3.2.1.3 询问地址段
询问地址段由5个字符组成，用于在分离的总线上向认定的发送器请求传送的语句。
其前两个字符是询问装置的发送器标识符，接着两个字符是被询问装置的发送器标识符，最后一个字符是询问字符“Q”。
3.3.2.2 数据字段
3.3.2.2.1 概述
语句中的数据字段跟在定界符“，”和一定的有效字符（和编码定界符“^”）之后。专有语句中的数据字段只包含有效字符和定界符“，”与“^”。
由于存在变长数据字段和空字段，只有通过观察字段定界符“，”才能确定特殊数据字段在一条语句中的位置。因而对于接收器来说，要通过定界符的计数来确定字段位置，而不应该从语句的开始对接收到的总个数来计数。
对于固定长度的数字字段，如果有效数据位长度不够，则应在前面补上足够数量的ASCII码字符“0”，以满足长度要求。
3.3.2.2.2 数据字段的类型
数据字段可以是字母型、数据型、字母数据型、可变长度、固定长度和固定/可变长度。有些字段是常量，其值由专门的语句规定，允许使用的字段类型见表4。
表4 数据类型说明
3.3.2.2.3 空字段
空字段指长度为零的字段（没有传递任何字符），当数据不可靠或不可得时，应该使用空字段。带有定界符的空字段有以下形态：“,,”“，”。
不应该把ASCII零字符（HEX00）作为空字段。
3.3.2.2.4 可变长字段
字段的长度可变，以适应各装置的能力或要求，传递信息和提供不同精度的数据。
可变长字段可以是字母数字字段，也可以是数字字段。可变的数据字段可包含一个小数点，开头和结尾可以是几个“0”。
3.3.2.3 和校验字段
和校验字段是语句中的最后一个字段，它在定界符“*”之后。
和校验是对语句中所有字符的8为（不包括起始和结束位）执行OR（异或）运算。所有字符指在定界符“＄”或“！”与“*”之间（但不包括这些定界符）的全部字符，其中包括“，”和“^”在内。发送时将16进制的高4位和低4位转换成两个ASCII字符（0～9，A～F）。最高有效位首先发送。
3.3.3 语句
3.3.3.1 概述
语句以语句起始定界符“＄”或“！”开始，以语句终止符
在一条语句中，字段数最少为1个。第一个字段应该是地址字段，其中包含发送器的标识符和语句格式符，该格式符规定语句中数据字段的个数、所含数据的类型、以及数据段的传送顺序。语句的其余部分可以是零个或多个数据段。在语句中可以出现空字段，如果某字段的数据不可靠或不可得，就应用空字段。
3.3.3.2 通用语句
通用语句是为一般用途而设计的。一条通用语句包含下列要素（按出现的顺序）：$<语句类型标识>，<数据字段>，<数据字段>，……<数据字段>*<校验和>
a）参数语句：
参数语句是数据接口最常用的语句，其基本格式：$IDsss,d1，d2，……，dn*hh
参数语句的类型标识（IDsss）由两部分组成。前两个字符（ID）为语句标识符，后3个字符（sss）为语句格式符。类型标识符字段之后为数据体，由若干数据字段（d1，d2，……，dn）组成。
b）询问语句：
询问语句用于发送器请求接收器向已方发送一条特定的标准语句。使用询问语句意味着接收器有能力用自己的总线成为一个发送器。询问语句基本格式：$ttllQ，ccc*hh
字符“$”之后的字符（ttllQ）为地址字段。其中，前两个字符（tt）为请求者的发送器标识符，中间两个字符（ll）为被请求这的发送器标识符，最后一个字符（Q）作为询问语句的标识符。数据段（ccc）为被请求发送的语句。
用语句对询问语句作应答。询问语句需要相互连接装置之间的配合，对询问语句的应答不是强制性的。对一条询问语句最多只应答一次。
示例：$CCBDQ，GGA*hh
注：此句表示请求者“CC”（计算机）请求BD-2用户设备输出GGA语句。
c）专用语句：
用户可通过专用语句对接口协议进行扩展，用于设备测试或传输专用数据。专用语句格式：$Psaaa，d1，d2，……，dn*hh
类型标识（Psaaa）中，字符P为专用语句标识符，“s”为制造商自定义标识符，长度为一个字符，取值范围为A～Z；后3个字符（aaa）为制造商定义的专用语句格式符。
专用语句应包括校验和、字段分隔符、校验和定界符，且符合语句长度限制。专用数据字段的其他要求由设备制造商自定。
3.3.3.3 有效语句
通用语句和专用语句都是有效语句，其它任何形式的语句都不是有效的语句，不得在总线上进行传输。
3.3.3.4 多语句信息
当一条数据信息超过了单条语句的可用字符空间时，可以传送多语句信息。支持多语句信息能力的关键字段应该始终包含在内。这些必要的字段是：语句的总个数、语句号数以及顺序信息的标识符字段。只有语句包含了这些字段才能形成信息。
接收器必须检验多语句是相邻连续的。当一条多语句信息被高优先级的语句打断，使原信息不完整，接收器应予放弃，等待重新发送。
如果多语句信息中任一条语句出现错误。接收器应放弃整条信息，接收下一次发送的信息。
3.3.3.5 语句传送定时
定时的语句传送频度应符合通用语句的定义。除另有规定，该速率就应与基本的测量或计算周期一致。
语句应以最小字符间距传送，间距最好接近连续脉冲，完整传送一条语句的时间不应大于1 s。
3.3.3.6 通用语句的补充
当修改现有语句时，可在最后字段后面和校验定界符“*”与和校验字段之前，增加新数据字段来修改现有的语句。接收器应该通过识别
3.3.4 错误检测和处理
接收器应能检测数据传送中的差错，包括：
1.和校验错误；
2.无效字符；
3.不正确的发送器标识符长度、语句格式符和数据字段；
4.语句传送超时；
5.接收器只使用与本标准相符合的准确语句。
3.4 数据内容
3.4.1 字符定义
预留字符见表1，数据类型见表2，发送器标识助记符号见表3，通用标识符见表4。
3.4.2 RNSS语句格式
3.4.2.1 AAM
功能描述：双向语句。航路点到达报警。当用户设备达到航路点c-c的报警区域（进入到达圈，或通过航线的垂线）时使用本语句，见表5。格式：$--AAM,A,Ax.x,u,c--c*hh
表5 AAM语句格式说明
?注1：双向语句指用户设备可以接收或发送的语句。
?注2：为方便对格式各字段含义进行说明，编号从格式中的类型标识后的第一个字段进行依次编号，至校验和前一个字段结束。
?注3：“——”表示本项内容不做描述或规定。
?注4：本字段可以传输汉字，传输汉字时，则该字段传输内容为计算机内码，每个汉字16bit，高位在前。
3.4.2.2 ALM
功能描述：双向语句。描述卫星历书数据。用户设备收到本语句后，以本语句内容设置初始化卫星历书数据；用户设备输出本语句时，用于描述用户设备接收的卫星历书数据。本语句包含了卫星星期计数、卫星健康状态和一颗卫星的完整历书数据，每颗卫星传送一条。如果传送BD、GPS、Galileo等卫星历书数据，分别使用ALM语句，用标识符BD表示传送BD卫星历书数据，用GP表示传送GPS卫星历书数据，用GA表示传送Galileo卫星历书数据等，见表6。GN标识符不应当与本语句一起使用。格式如下：$--
ALF,x.x,x.x,cc,xxx,hh,hhh,hhhhh,hh,hhhh,hhhhh,hhhhhh,hhhhhh,hhhhhh,hhhhhh,hhh,h hh*hhh
表6 ALM语句格式说明
3.4.2.3 ALF
功能描述：注入卫星历书数据。本语句适用于向BD-2用户设备注入BD-2和GPS卫星历书。注入多颗卫星数据使用多条语句传输，每一颗卫星对应一条注入语句，见表7。格式如下：1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | | | | | | | | | | | | | | | | | $--
ALF,x.x,x.x,cc,xxx,hh,hhh,hhhhh,hh,hhhh,hhhhh,hhhhhh,hhhhhh,hhhhhh,hhhhhh,hhh,h hh*hh
表7 ALF语句格式说明
数据管理办法 第一章总则 第一条为适应集团信息化发展要求,充分利用数据资源为生产、经营、管理和决策服务，保证各类信息合理、有序流动和信息安全，确保集团信息化建设快速协调有序安全发展，根据国家有关法律法规以及《集团信息安全管理办法》（中平〔2013〕188号）、等规定，特制定本管理办法。 第二条本办法适用于集团各职能部室，直属和特设机构、专业化公司、事业部、区域公司及其所属各单位（以下简称各单位）。 第二章管理范围 第三条本办法管理范围包括：各单位与生产、经营、办公、安全等相关的应用系统和数据，以及为其提供支撑的基础设施资源、计算存储资源和办公终端资源等。 第三章组织机构和工作机制 第四条集团信息化领导小组是集团数据资源管理体系的最高层，负责审定集团有关数据资源管理的规章、制度、办法，负责审核有关标准、规范、重要需求等。集团信息化领导小组办公室（以下简称集团信息办）负责集团数据管理的监督、检查和考核，指导集团数据管理工作，查处危害集团数据安全的事件。各单位负责本单位数据的采集、传输、使用、安防、备份等管理
工作。中国平煤神马集团平顶山信息通信技术开发公司（以下简称信通公司）作为技术支撑及运维部门，负责集团数据中心的运维和运营工作。 第四章数据分级管理 第五条根据数据在生产、经营和管理中的重要性，结合有关保密规定，按照集团级应用系统和数据、厂矿级应用系统和数据、区队（车间）级应用系统和数据分别制定管理标准。 第六条集团级应用系统和数据，技术管理由集团信息办负责，业务管理由相关业务处室负责，运维管理由信通公司负责。厂矿级应用系统和数据由各单位信息管理部门管理，集团需要利用的管理数据和生产数据要同步上传到集团数据中心。区队（车间）级应用系统和数据由各单位信息管理部门管理和维护。 第五章数据标准管理 第七条集团信息办负责集团数据编码和接口标准的统一规划和标准制定，负责对集团及各单位应用系统的数据标准管理进行引导和考核。各单位新建应用系统应严格执行集团下发的数据编码和接口标准，在用应用系统应根据自身实际逐步按照集团标准进行完善。 第八条数据编码和接口标准应符合以下要求： （一）数据编码应能够保证同一个对象编码的唯一性及上下游管理规范的一致性；
密级：用户需求说明书模板 软件开发项目xx组 二О一六年八月二十七日文件修订记录
目录 1. 概述 (4) 1.1编写目的 (4) 1.2用户简介 (4) 1.3项目的目的与目标 (4) 1.4术语定义 (5) 1.5参考资料 (5) 1.6设计与实现的限制 (5) 2. 现有系统的描述 (6) 2.1组织机构与职责 (6)
2.3作业流程 (7) 2.4报表 (7) 2.5存在的问题 (7) 2.6可能的变化 (8) 3 功能需求 (8) 4 界面与接口需求 (9) 4.1用户的界面需求 (9) 4.2外部的接口 (10) 5 性能需求 (10) 5.1时间要求 (10) 5.2空间与数值性能 (10) 6 其他需求 (11) 6.1系统的安全性 (11) 6.2系统的可靠性 (11) 6.3系统的灵活性 (11) 6.4其他 (11) 7 非功能需求 (12) 7.1用户特点 (12) 7.2法律法规、版权 (12) 7.3兼容性 (12) 7.4联机帮助信息 (12) 7.5购买组件 (12) 8 系统约束 (12) 9用户验收标准 (13) 9.1验收标准： (13) 9.2功能验收标准可依据以下方面制定： (13) 9.3性能验收标准： (13) 附录A ××× (16) A.1××× (16)
附录B ××× (16) B.1××× (16) B.2×××161. 概述 1.1 编写目的 为了使用户与开发人员之间相互了解，对用户需求进行明确定义，使之成为整个开发工作的基础，并提供一个软件系统度量和遵循的基准。该文件可作为用于确认软件产品是否满足给定需求的验收标准。 1.2 用户简介 在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围，进行关于功能与进度、成本、性能等方面的平衡决策。 基本情况举例： ?企业性质 ?规模（员工数量、经营业绩等） ?业态 ?地理位置与布局 ?产品或服务的种类 ?管理模式 ?用户使用计算机系统的经历 ?…... 1.3 项目的目的与目标 项目目的是开发本系统的意图的总概括，目标是将目的细化后的具体的描述，项目目标应是明确的、可度量的、可以达到的,项目的范围应能确保项目的目标可以达到。
客户交易结算资金监控系统数据接口规范
1.总则 1.1定位 本规范适用于结算公司、存管银行、结算银行向中国证监会报送《客户交易结算资金管理办法》中第九、二十条规定的数据。本规范规定的数据内容和格式，要求在各机构与中国证监会数据往来时予以遵守，内部系统使用的数据内容和格式不受本规范的约束。 本规范根据业务的发展进行动态调整。 1.2适用范围 本规范规定的数据格式适用于按照中国证券监督管理委员会令第三号《客户交易结算资金管理办法》中第九、二十条向中国证券监督管理委员会报送之数据。 1.3版本控制 客户交易结算资金监控系统建设小组负责建立本规范的维护机制，保证本规范的完善和发展。 本规范向结算公司、存管银行、结算银行开放，各机构可以向小组提出增加数据的申请，小组决定是否进行修改。对本规范进行修改后，即定义一个新的版本。 2.引用参考标准 无 3.术语定义 报送单位—向中国证监会上报数据的结算公司、存管银行、结算银行。
被统计单位—结算公司、各证券公司及下属证券营业部。 统计日期—上报数据的统计日期。 其他—参见《客户交易结算资金管理办法》第三十七条释义。 4.基本要求 4.1数据传输： 数据传输为文本文件。 4.2 数据处理规则： （1）字符不区分大小写 （2）数字左补零右对齐，字符右补空格左对齐 （3)日期类型为YYYYMMDD （4）金额单位为元 （5）行结束标志为回车换行。 4.3文件命名： 文件命名规则为：类别码+“_”+报送单位代码+“_”+统计日 期.TXT 4.4 文件结构定义： 文件结构包含文件头、数据字段说明和报送记录三个部分
5.数据格式 存管银行总部向机构部报送的数据格式 (类别码A) 结算公司向机构部报送经纪资金、自营资金的数据格式（类别码B） 结算银行向机构部报送结算公司的清算备付金和验资专户账面余额的数据格式（类别码C）
附件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 !!! 致力为企业和个人提供合同协议，策划案计划书，学习课件等等 打造全网一站式需求 欢迎您的下载，资料仅供参考
{业务管理}数据业务管理平台接口规范分册
QB-GF-003-2003 移动数据业务管理平台(D S M P ) 接口规范 版本号：1.5.0 中国移动通信集团公司 发布 2003-1-31发布 2003-1-31实施 M o b i l e D a t a S e r v i c e M a n a g e m e n t P l a t f o r m I n t e r f a c e S p e c i f i c a t i o n
目录前言III 1 适用范围1 2 引用标准2 3 相关术语与缩略语解释4 4接口命名规范5 5 接口在网络中的位置6 6系统接口描述7 6.1 DSMP对外接口描述7 6.2接口消息实现8 7 字段类型说明8 8 DSMP接口定义8 8.1 DSMP与业务网关之间的接口(Sg接口)8 8.2 DSMP与BOSS系统接口(Mb接口)8 8.3 DSMP与SCP接口(Sscp接口)8 8.4 DSMP与客服/1860之间的接口(Sk接口)9 8.5 DSMP之间的接口(Sim接口)9 8.6 DSMP与SP之间的接口(Ma接口)9 8.6.1 DSMP与SP之间接口消息定义9 8.6.2 DSMP与SP之间接口消息体定义9 9 返回值的统一定义11
10 编制历史15 附录A 模式（schema）描述16 Schema字段描述16 附录B DSMP与SCP之间通信协议中共用的通用元素的定义17 附录C DSMP平台Web Services 数据类型定义17 附录D DSMP平台Web Services 接口定义和SOAP绑定19 1 DSMP平台Web Service接口设计和开发准则19 2 举例说明20 3 DSMP接口的WSDL定义23
用户需求说明书公司内部档案编码：[OPPTR-OPPT28-OPPTL98-OPPNN08]
用户需求说明书模板文档编号：用户需求说明书模板 文档信息：公司级别模板文件 文档名称：用户需求说明书模板 文档类别：工程过程类 密级：机密 版本信息：1.0 建立日期： 创建人： 审核者： 批准人： 批准日期： 保管人： 存放位置：
目录 1.引言 引言部分应包括：
1.1编写目的 主要说明本文档的作用，除了作为需求规格说明书提供后续设计和测试工作的依据外，如果作为项目验收的依据或有其他特别作用，应特别声明。 1.2范围 对于所有受到本文档影响或于影响这个文档的一切进行简明描述。 1.3项目背景 主要说明项目的来源，项目所涉及领域的现状，建设该项目的意义等。 1.4主要业务名词和术语定义 对本文档中所使用的专业或行业术语所指对象或含义进行解释性的说 明，特别是对在本文档中为描述业务方便而自行定义的一些名词如“**类别”、“**状态”等进行说明，在后文论述中可直接加以引用。 1.5参考文献 * 列明制定本文档所参考的资料清单，说明其作者和出版日期。 2.需求概述 2.1用户当前系统 * 2.1.1用户当前系统概述 主要说明用户当前系统覆盖的业务范围、实现的主要功能、业务流程以及与其他系统的关系 2.1.2用户当前系统存在的问题 主要说明用户当前系统存在的问题
2.2目标系统 2.2.1目标系统概述 主要说明系统实现的主要功能；在系统实现过程中应考虑的主要问题； 系统实现的基础（是否已有类似经验）；系统所采用的主要技术。 2.3与其他系统的关系 * 列明与本系统有联系的系统包括直接发生业务关系的其他计算机系统，或直接有业务关系的系统，并说明他们之间的关系。 2.4边界定义 概括说明系统覆盖的业务范围；说明系统包括和未包括的处理功能，对包括的处理功能可参见系统功能模型的描述，对未包括的的业务功能无需穷举，只需说明与本系统功能相关但不属于本系统处理范围的功能。 2.5基本业务规则 系统所涉及的业务领域通常存在不同的处理规范或标准，本节主要描述本系统业务所基于的业务处理规范或标准，使读者对主要业务规则有基本了解。如果基本业务规则不同，则可能会使系统设计产生比较大的改动。 2.6系统功能模型概述 说明系统功能的划分，列举划分的子系统，对子系统功能做简短说明，说明子系统的功能划分，列明子系统所包含的下一级业务处理单元。 2.7安装或实施目标系统的策略 主要说明数据转换的策略，当前系统与目标系统衔接的策略（例如并行使用一段时间），包括系统服务端、客户端、应用服务器等安装的地点及数量等。 2.8目标系统运行环境要求 说明应用软件要求的运行环境。
深交所第四版数据接口规范的补充说明 在2001年6月11日新版数据接口规范全国工作会议广泛征求意见的基础上，我所技术人员通过认真的分析研究，决定对新版数据接口规范作如下补充： 一、增加新股发行有效申购数据的发放 在新股发行的中签当日，系统通过股份结算信息库（SJSGF.dbf）同时发放两类数据。一类是全部有效申购数据（GFYWLB=A6），用于解冻股民申购资金；另一类为中签数据（GFYWLB=A3），用于扣除股民新股资金。 GFYWLB=A6的记录具体定义如下：GFQRGS=申购股数，GFZJJE=申购价格，GFQRGS*GFZJJE=解冻资金。 二、证券信息库增加一条特殊记录 类似于行情库，在证券信息库中增加一条特殊记录，用于存放证券信息库（ＳＪＳＸＸ．ＤＢＦ）最近一次更新的日期、时间以及当日挂牌证券数量等信息。具体为：证券信息库的第一条记录为特殊记录，ＸＸＺＱＤＭ（字段１：证券代码）为“００００００”，ＸＸＺＱＪＣ（字段２：证券简称）存放当前日期ＣＣＹＹＭＭＤＤ，ＸＸＢＬＤＷ（字段１８：买数量单位）存放库更新时间，ＸＸＳＬＤＷ（字段１９：卖数量单位）存放当日挂牌证券的数量。 三、证券信息库中的交易状态字段增加“增发股份上市”状态定义 证券信息库（ＳＪＳＸＸ．ＤＢＦ）中的交易状态增加一类信息：增发股份上市。即ＸＸＪＹＺＹ（字段２７：交易状态）：‘Ｙ’首日上市；‘Ｚ’增发股
份上市；‘Ｎ’通常状态；‘Ｆ’新股上网定价发行；‘Ｉ’新股上网竞价发行；‘Ｐ’国债挂牌分销。 四、增加行情状态标志信息 在行情库（ＳＪＳＨＱ．ＤＢＦ）的特殊记录中增加行情状态信息。具体说明为：行情库第一条记录为特殊记录，ＨＱＺＱＤＭ为“００００００”，ＨＱＺＱＪＣ存放当前日期ＣＣＹＹＭＭＤＤ，ＨＱＣＪＢＳ存放当前时间ＨＨＭＭＳＳ，ＨＱＺＲＳＰ存放“指数因子”，ＨＱＣＪＳＬ存放行情状态信息。ＨＱＣＪＳＬ个位数存放收市行情标志（０：非收市行情；１：表示收市行情），ＨＱＣＪＳＬ十位数存放正式行情与测试行情标志（０：正式行情；１：表示测试行情），即ＨＱＣＪＳＬ值为０时表示正式非收市行情，为１时表示正式收市行情，为１０时表示测试的非收市行情，为１１时表示测试的收市行情。 五、委托库中的委托记录错误代码使用说明 委托库（ＳＪＳＷＴ．ＤＢＦ）中的ＷＴＣＬＢＺ（字段８：处理标志）表明本委托记录的处理状态。由券商系统置初始值为‘ｚ’；通信程序处理完本委托后将其置为非‘ｚ’的值，如本委托为合法记录，则将其传送给深交所主机，并将ＷＴＣＬＢＺ置为‘１’，如非法则将其置为对应的错误代码。错误代码定义见接口规范之“委托记录错误代码含义表（表三）”。 对于增加错误委托库的意见，经研究，认为无此必要。字段ＷＴＣＬＢＺ已明确表明委托是否经通信系统处理且是否合法的状态信息，券商系统很容易实现对委托状态的跟踪，并根据ＷＴＣＬＢＺ值作相应的处理。其粗略的参考算法示意如下：
监管报表数据报送接口规范修订历史纪录
一、销售机构、基金资金划付明细文件格式建议（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）业务，统计的基金应付金额为：汇总每笔交易的（投资人实得现金红利金额）。
附件2 武汉市节能智慧管理系统 数据接口规范 武汉市发展和改革委员会 2013年12月
前言 为指导我市各级节能智慧管理系统建设，市发改委组织有关专家，以我国现行相关标准为依据，结合我市节能智慧管理系统建设、验收和运行管理要求，研究制定了本数据接口规范。 本规范包括主要用能单位上传数据接口标准规范和市区各级系统上传数据接口标准规范两部分，其中两部分包括了接口的标准应用范围、接口的实现、接口的要求、术语和定义和基本原则。 本规范由市发改委负责管理和解释。
目录 1. 主要用能单位上传数据接口规范 (5) 1.1标准应用范围 (5) 1.2术语和定义 (5) 1.3基本原则 (5) 1.4接口实现 (6) 1.4.1数据提供方 (6) 1.4.2数据接收方 (6) 1.4.3接口的实现方式 (7) 1.4.4传输方式 (7) 1.4.5传输协议 (7) 1.4.6传输过程 (7) 1.4.7编码原则 (8) 1.4.8接口的验证方式 (8) 1.4.9使用策略 (9) 1.5接口数据的要求及保障 (9) 2. 区分系统上传数据接口规范 (10) 2.1标准应用范围 (10) 2.2术语和定义 (10) 2.3基本原则 (10) 2.4接口实现 (11)
2.4.1数据提供方 (11) 2.4.2数据接收方 (12) 2.4.3接口的实现方式 (12) 2.4.4传输方式 (12) 2.4.5传输协议 (12) 2.4.6传输过程 (12) 2.4.7编码原则 (13) 2.4.8接口的验证方式 (13) 2.4.9使用策略 (14) 2.5接口数据的要求及保障 (14) 附录1 数据采集器身份认证过程和数据加密 (15) 附录2 数据采集器或子系统和市数据中心通信过程 (16) 附录3 数据传输的XML数据格式 (17)
中国财务软件数据接口标准(DOC7) 编者按:标准应该是衡量事务的准则。标准的制定一样都由国际/国家有关标准机构或行业主管部门完成。但一些行业的生产厂商为了爱护用户的投资,促进行业有序进展,也按照本行业的特点,联合起来制定了一些大伙儿认可并共同遵守的规范,这种做法在国外已被广泛采纳。随着中国改革开放的深入,国内一些行业的厂家也开始进行这方面的探究,本期我们刊登的《中国财务软件数据接口标准》确实是由该财务软件行业的民间组织——中国软件行业协会财务及企业治理软件分会制定的,起草者为闻名财务软件厂商深圳金蝶公司。 一、背景 目前,国内财务软件众多,它们采纳的数据库平台和数据库结构各不相同,不同财务软件之间的数据交换,因为数据库平台和结构不同而产生许多困难,几乎任意两个不同软件之间要实现数据传递都会存在专门的数据转换咨询题。烦琐的数据转换工作白费了大量人力和物力,同时也阻碍了财务软件产业的健康进展。国内财务软件的商业化差不多比较成熟,各财务软件公司都有一批用户。由于各种缘故,一些用户期望从一个软件交叉升级为另一软件。由于用户在旧软件上已做了大量的工作,必定期望升级后原有数据能移植到新的软件中,然而有些软件的数据文件通过加密或数据库结构未公布,要从中直截了当读取数据几乎不可能。为了爱护用户已付出的劳动,各财务软件需要提供一个标准的数据输入输出接口。如此,建立一个公用的数据交换标准是专门必要的。 用户在使用财务软件时,有一些需求通过财务软件本身是难以实现的,如:用户期望把会计报表通过电子表格软件处理输出为各种专门形式;另一些高级用户,则期望在其它治理软件中能取到财务数据。这些数据交换工作都需要有一个标准的数据接口来规范。财务会计通过长期的进展已形成一定的理论,财务会计工作也有规范可循,国内财务软件是在这些理论和规范的基础上开发出来的,各软件储存财务数据的模式也大同小异。财务数据要紧按会计科目、凭证、余额及发生额、报表几个部分分块储备,它们之间既
资金划拨数据接口规范 （券商部分） 如果接口对外开放，这部分内容可酌情合并到深交所数据接口或参与人数据接口文档。
1.资金交收上行库ZJSXK.dbf (1)必填项为所有申请交易必须填写的字段，非必填项字段将根据不同交易有不同定义，具体说明请详见交易填报字段说明表，表6-3。
(2)SXJGBS(字段1：结算账户)，6位结算账户编码（左对齐右补空格），又叫资金结算主席位，用于交易申请数据的安全性检查，限制参与人只能发送属于自己结算账户下的数据。 (3)SXJYDM(字段2：交易代码)，含义详见表6-1。 (4)SXSQLS(字段3：申请交易流水)，交易流水号，当日内不得重复。 (5)SXMXZH（字段4：结算备付金账号），结算公司为结算参与人开立的备付金账号，接口中该字段长度定义为20位，实际使用前10位（左对齐右补空格）。?结算备付金账号?一般为科目代号（4）+席位代码（6） (6)SXDWMC（字段5：单位名称），收/付款单位名称（左对齐右补空格）。 (7)SXSKHH（字段8：收款银行行号），收款银行电子联行号（左对齐右补空格）。 (8)SXSKZH（字段9：收款银行账号），收款银行账号（左对齐右补空格）。 (9)SXFKHH（字段10：付款银行行号），付款银行电子联行号（左对齐右补空格）。 (10)SXFKZH（字段11：付款银行账号），付款银行账号（左对齐右补空格）。 (11)SXFKHM（字段12：付款银行名称），付款银行账号所在开户行名称（左对齐右补空格）。 (12)SXFKTD（字段13：付款银行提单号），付款银行在付款时生成的提交号，当日内不可重复。 (13)SXJZRQ（字段14：银行进账日期），银行实际收款进账日期。 (14)SXCXLS（字段15：撤销交易流水），撤销交易中填写被撤销交易的申请流水。 (15)SXBMMY（字段16：变码密押），将数据记录中所有字段参与运算后生成，用以校验记录是否被非法篡改。 (16)SXZYNR（字段17：摘要内容），用于记录交易中相关补充、摘要信息。 (17)SXSQRQ（字段18：申请日期），交易申请日期。 (18)SXSQSJ（字段19：申请时间），HH表示小时，MM表示分钟，SS表示秒钟，XX备用，一般写00。对于响应类交易，该字段填写其所对应的原申请交易时间。 (19)SXSKBS(字段22：收款笔数)，结算备付金账户当日存款笔数。 (20)SXSKJE(字段23：收款金额)，结算备付金账户当日存款金额。 (21)SXCSBS(字段24：撤销收款笔数)，结算备付金账户当日撤销的存款笔数。 (22)SXCSJE(字段25：撤销收款金额)，结算备付金账户当日撤销的存款
中国结算开放式基金新版系统管理人数据接口规范(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)
用户需求说明书与需求规格说明书的区别 1、用户需求说明书是用户的需求（期望），需要和用户确认的，重点是站在客 户的角度讲产品功能。需求规格说明书是系统设计需求，主要是对内的，是 从开发、测试的角度去讲产品功能。 2、优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员的 文档。缺点：层次越多，信息损失的越多，误解的概率就越大。权衡的结 果：基本上是依据项目的规模而定。 3、如果要省掉一个的话，更倾向于写用户需求，因为搞系统的时候要始终明白 用户在想什么，要解决什么问题。需求规格相对不是很重要，具体实现用户 需求的时候，你可以有各种方案，这个是用户不关心的。要是用户需求就已 经理解错了，特别是理解不全面，软件规格说明书写得好让用户签字就没有 任何意义了。 4、最新的做法 使用UML语言，开发需求用例说明书，用例、场景描述和事件――响 应表，既可面向客户，又可面向开发设计； 使用敏捷开发方法，通过用户故事描述用户需求，即客户想要实现 一个什么功能，以满足某个方面的需求。 【相关知识】 “需求管理”的文档大体上包含需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件。 “需求开发”的文档大体上包含需求规格说明书，需求规格说明书检查表， 需求开发指南等。 需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告， 重点是体现出产品要满足哪些功能，哪些是重点、热点。 需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，CMMI 中有标准的模板，重点是站在客户的角度讲产品功能。
需求规格说明书：是从业务规则讲起的，细一点偏向于软件的需求设计到概 要设计。是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务 接口、活动图等。 业务需求（Business requirement）表示组织或客户高层次的目标。业务 需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销 部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织 希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或market requirement）文档。 用户需求（user requirement）描述的是用户的目标，或用户要求系统必 须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效 途径。也就是说用户需求描述了用户能使用系统来做些什么。 功能需求（functional requirement）规定开发人员必须在产品中实现的 软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也 被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。注意：用户需求不总是被转变成功能需 求。 产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为 用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组 能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重 号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是 一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求， 以便用户能够执行某项任务。 系统需求（system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件 子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。 业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业 务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，
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设计原则
项目名称 用户需求说明书
文档修改摘要
目录 1文档简介 (4) 1.1文档目的 (4) 1.2范围 (4) 1.3名词定义 (4) 1.4参考文件 (4) 2系统概述 (5) 2.1系统介绍 (5) 2.2系统目标 (5) 2.3系统范围 (5) 2.4系统面向用户群体 (5) 2.5遵循的标准与规范 (5) 3功能需求 (6) 3.1系统总体功能 (6) 3.2功能需求1 (6) 3.3功能需求2 (6) 4非功能需求 (7) 4.1用户界面需求 (7) 4.2软硬件环境需求 (7) 4.3接口需求 (7) 4.4性能需求 (7) 4.5品质需求。 (7) 4.6安全与保密需求 (8) 4.7扩展性需求 (8) 4.8其他需求 (8) 5需求优先级 (9) 6附录 (10)
1文档简介 本章将简要地说明用户需求说明书(以下简称本说明书)的目的、范围、读者对象、名词定义和参考文件 1.1 文档目的 本说明书的目的在于阐明XXXXXX系统(以下简称本系统)的用户需求。 本说明书为编制其它有关文件提供基本依据。 本说明书收集和整理了客户的需求，并提供作为与客户讨论和确认需求的依据。 1.2 范围 本用户需求说明书的内容涵盖了客户提出的业务、非功能需求等。 本说明书的阅读、使用者包括： 项目管理人员 软件设计人员 编程人员 软件测试人员 软件质量控制人员 软件维护人员 用户代表（需求方、需求部门主管） 1.3 名词定义 提示：准确地解释本说明书所涉及的字头词和缩写词 1.4 参考文件
2系统概述 提示：本章将简要地进行本系统的介绍、说明系统目标、范围、面向群体与标准规范。 2.1 系统介绍 提示：系统介绍主要说明系统的特征、用途、背景等。 2.2 系统目标 提示：说明本系统所要达到的目标。 2.3 系统范围 提示：（简单描述）说明本系统所涵盖的范围，例如： ●业务范围 ●组织范围 ●功能范围 本子章节应提供软件所实现功能的一个概要描述。例如，对一个财务软件的SRS，我们应在此部分说明用户帐户维护，用户声明和发票准备等功能，对每个功能进行大量的细节说明放在功能需求或者非功能需处说明。 2.4 系统面向用户群体 提示：描述本系统面向的用户（客户、最终用户）特征，说明产品对他们的用处，带来的利益等。 2.5 遵循的标准与规范 提示：描述本系统遵循的标准与规范。
软件开发管理办法 修订记录 版本编号修订日期主要修订摘要 审核记录 审核人员属于部门审核日期 第一章总则 第一条为规范公司的开发管理流程，使各开发项目的管理进行标准化管理，特制定本管理办法。 第二条本管理办法详细规定软件开发程的各个阶段及每一阶段的任务、要求、交付文件，使整个软件开发过程阶段清晰、要求明确、任务具体，实现软件开发过程的标准化。 第三条本管理办法适用于计算机的自主软件开发项目。适用对象：软件开发管理人员，软件开发人员，软件维护人员，系统管理人员。 第二章组织机构与职责 第四条软件开发管理人员职责： 第五条软件开发人员职责： 第六条软件维护人员职责： 第七条系统管理人员职责： 第三章软件开发环境管理 第八条软件建设环境根据项目不同的时期，需要搭建生产运行环境、系统测试环境、系统开发环境三种不同的软硬件网络环境，便于生产、开发、测试等工作的安全、顺畅的进行。 第九条生产环境为系统维护管理人间管理的范畴，是系统正式运行，提交给各业务科室的正式环境，包括系统运行的硬件、网络等设备和进行集群处理的软件系统。 第十条测试环境为测试人员提供功能测试、性能测试的运行环境，包括运行环境模拟、测试工具服务器、测试工具客户端。 第十一条开发环境为系统开发人员提供系统开发需要的软件硬件环境，包括数据库服务器、应用服务器、开发工具客户端。 第十二条生产环境、测试环境、开发环境都存在自己独立的数据库服务器、应用服务器、客户端。在开发环境完成内部测试后，提交发布版本到测试环境中，由专门的测试人
员进行集成测试和功能测试。并进行一定的压力性能测试。在测试环境通过的版本在发布到生产环境。 第十三条生产环境与测试环境、开发环境需要物理隔离，保障生产环境的安全。 第四章开发过程管理 第十四条项目开发流程根据软件工程的流程，分为可行性研究与计划、需求分析、总计设计、详细设计、代码开发、系统测试五个阶段。 第十五条可行性研究与计划 1实施要求 1.软件开发部分析人员进行市场调查与分析，确认软件的市场需求 2.在调查研究的基础上进行可行性研究，写出可行性报告 3.评审和审批，决定项目取消或继续 4.若项目可行，制订初步的软件开发计划，建立项目日志 5.根据市场环境、公司软硬件情况预测十大风险因素 2交付文档 1.可行性研究报告* 2.初步的软件开发计划 3.十大风险列表* 4.软件项目日志* 第十六条需求分析 1实施要求 1.调查被开发软件的环境 2.软件开发提出的需求进行分析并给出详细的功能定义 3.做出简单的用户原型，与用户共同研究，直到用户满意 4.对可利用的资源（计算机硬件、软件、人力等）进行估计，制定项目进度计划（可 有相应的缓冲时间） 5.制定详细的软件开发计划 6.测试人员制订质量控制计划和测试计划 7.编写初步的用户手册 8.进行需求方案评审 2交付文档 1.软件需求说明书 2.更新后的软件开发计划 3.项目进度计划 4.计划
葵花药业集团 （唐山）生物制药有限公司自动装盒机用户 需 求 标 准 二O一三年四月
1、综述 背景：根据公司发展战略要求，在新园区新建年产颗粒剂8.2亿袋、片剂11亿片、胶囊剂8亿粒的口服综合制剂车间，因此，需新购铝塑包装机1台，枕式包装机 2台，全自动装盒机2台（药板型装盒机），电子扫描机2台，激光打码机2台， 印字打包一体机2台。 目的：为用户和供应商提供铝塑包装机，枕式包装机，装盒机，电子扫描机，激光打码机，印字打包一体机的设计、制造、采购、验收和确认依据。 范围：本URS适用于铝塑包装机，枕式包装机，装盒机，包括装盒机。 责任：需方对本URS的编制质量负责。供方须严格按照本URS所明确的法规标准、技术要求、服务要求，提供相关设备设施和服务，供方须对需方所提供的URS负 保密责任。 工艺描述：药片通过铝塑机进行包装，形成平整的铝塑板，铝塑好的药板经枕式包装后传送带或者手工进入装盒机料仓，通过自动下料装置传送轨道上，纸盒由纸盒贮存仓被吸嘴打开后送到装盒工位，说明书由说明书贮存仓经折叠后送到装盒工位，由推舌将药板及说明书送入张开的纸盒中，再经过折盒封好后，进入装盒机出口传送带，经传送带进入下一工序进行操作。 2、法规标准 法规： 除本URS特殊要求外，须满足中国的2010版《药品生产质量管理规范》法规要求，中国安全环保法规。 标准： 除本URS特殊要求外，须满足ISPE（国际制药工程师协会）所颁布的制药工程设备标准、中国制药装备协会所颁布的制药工程设备标准、ISO14001、OSAHS18001、压力容器和特种设备中国国家制造标准。 3、技术要求 3.1生产工艺要求 铝塑包装机 需求编号需求必需/期望 URS001 单机实际稳定运行速度可达到≥150冲/分钟（以连续生产1号胶囊为验收基准，标准排列板型93×56，横出2板/切，品字形排版，纵向版块与版块之间废边为1mm,2×6粒/板），最大成型面积260×250mm。 URS002 成品率：不低于99.5%（以连续生产3批1号胶囊为验收基准， 计算公式=实际成品数量/理论成品数量×100%）。 符合 URS003 PVC宽度：180-260mm，厚度：0.15-0.45mm；符合
郑商所期货交易数据交换接口规范 V3.5 Version3.5 本文档适用于ZCEAPI 1.1.3.4 郑州商品交易所 2019年12月
目录 修改历史 (1) 目的与说明 (5) 数据元类型 (5) 数据元定义 (5) 业务命令报文 (13) 交易员登录请求（PID）：0x00016 (13) 交易员登录应答（PID）：0x10016 (13) 交易员登录退出请求（PID）：0x00017 (14) 交易员登录退出应答（PID）：0x10017 (14) 交易员修改密码请求：（PID）：0x00018 (14) 交易员修改密码应答（PID）：0x10018 (15) 报单录入请求（PID）：0x00003 (15) 报单应答（PID）：0x10003 (16) 做市商报价响应录入请求（PID）：0x03003 (17) 做市商报价响应应答（PID）：0x13003 (17) 报单操作请求（PID）：0x00004 (18) 报单操作应答（PID）：0x10004 (18) 报单查询请求（PID）：0x00006 (18) 报单查询应答（PID）：0x10006 (19) 按定单类型报单查询请求（PID）：0x03010 (20) 按定单类型报单查询应答（PID）：0x13010 (20) 按本地定单号报单查询请求（PID）：0x03013 (21) 按本地定单号报单查询应答（PID）：0x13013 (22) 套期保值额度查询请求（PID）：0x03017 (23) 套期保值额度查询应答（PID）：0x13017 (23) 套期保值确认查询请求（PID）：0x03018 (24) 套期保值确认应答（PID）：0x13018 (24) 套利额度查询请求（PID）：0x03019 (25) 套利额度应答（PID）：0x13019 (25) 套利确认查询请求（PID）：0x03020 (25) 套利确认应答（PID）：0x13020 (26) 做市商报价响应查询请求（PID）：0x03026 (26) 做市商报价响应查询应答（PID）：0x13026 (26) 期权执行查询请求（PID）：0x03025 (27) 期权执行应答（PID）：0x13025 (27) 市场查询请求（PID）：0x0000B (28) 市场查询应答（PID）：0x1000B (28) 市场交易状态查询请求（PID）：0x0000D (28) 市场交易状态应答（PID）：0x1000D (28) 合约查询请求（PID）：0x00005 (29) 合约查询应答（PID）：0x10005 (29) 品种交易状态查询请求（PID）：0x0000E (31)