SOC系统集成测试用例和记录文本
SoC系统级软件测试
f u n c t i o n a l v e r i f i c a t i o nW h i t e P a P e rHybrid eSl/rtl co-verificationplatform for SyStem levelSoftware teStingpiotr K. luSzczaK, mentor grapHicSprepared for presentation at arm techcon 2011 (class code: atc-100)AbstrActHere’s one of the most oft-cited facts of semiconductor device design today: the increasing complexity ofsocs and multicore designs continues to create new verification challenges. Virtual platforms addresssuch challenges by abstracting designs to the transaction. However, such platforms introduce newproblems, including that hardware-software interface debugging is limited to high-level abstract EsLmodels. combining tLM 2.0 and rtL models allows for detecting hardware and software issues in greaterdetail than is possible with transaction level models alone. this paper discusses an EsL/rtL modelswapping technique that gives flexibility to debug and analyze systems at any development stage and onany hardware representation. the benefits of the technique include greater accuracy, optimizedperformance and faster product delivery.introductionAccording to the latest surveys, most SoC designs include one or more processors. This trend is due to theincreased cost of hardware verification for custom logic, the relatively flat cost of IP development and the broadavailability of synthesizable, high-performance and low-power processors. Verifying devices that include processorsrequires new techniques since hardware and software are involved in the final product.There are many approaches to this complex problem. One is traditional stimulation of the entire subsystem usingsequences based on the combination of constrained random and direct tests (the latter to cover corner cases).While the algorithmic approach enables relatively fast coverage closure, it does not include system-level softwareexecution on the processor. Typical examples of system software include BIOS or device firmware. The processor’sfirmware in particular can only be verified in relation to the hardware, thus the need for a system-level test thatexercises the program and checks if all elements of the integrated system are functioning properly.Running software on the processor model can be very slow during event-driven simulation at the RTL level. Oneway to speed things up is to abstract the design to the transaction level and simulate the SoC using a virtualplatform. Executing software on such a platform generates TLM 2.0 transactions.figure 1: General esl flow,including modeling, assembly,verification, analysis and theeventual virtual prototypetHE “Lt” And “At” siMuLAtion ModEs, And tHE LiMitAtions of A tLM-onLy ApproAcHCollecting and analyzing system software interactions with the TLM 2.0 based models allows for easy measurementcertain aspects of simulation coverage, which in turn enables advanced analysis. As shown in figure 1 on theprevious page, a typical ESL flow consists of modeling, platform assembly, verification, analysis and eventualcreation of a virtual prototype. There are two possible modes of simulation: loosely-timed (LT) and approximately-timed (AT). The LT mode allows runs the simulation faster and is suitable for executing simple software tasks. Theacceleration mechanism uses directed memory interface (DMI) for all memory accesses. Because the I/Ocomponents are accessed through the bus, which does not support DMI, the transactions are shown aspronounced spikes in LT simulation.The AT mode, in which CPUs, I/Os and memories are active and show correct transaction timing, enables morerealistic simulation. The timing information in this mode can be used to provide system performance data,including power consumption of different IPs at different times, transaction throughput from specific sockets andaverage transaction latency. Additionally, the processor core cache can be traced and analyzed through cachemonitors to allow display of I-cache and D-cache performance.The TLM level runs the virtual platform fast enough to execute system level software at a reasonable speed.However, the pure ESL verification platform lacks the ability to verify that the system level software, or morespecifically, that such software developed on the virtual platform using SystemC models for particular subsystemsworks with target hardware at the RTL level. A TLM-only approach does not allow for detection, repair andunderstanding of critical problems across different abstraction levels and language boundaries, a limitation whichmay lead to multiple software patches or, worse still, hardware respins. All too often, because of the large amountof legacy RTL IP that will be reused, a detailed RTL functional verification for portion of the design may still benecessary.figure 2: tlm simulationwaveforms for lt and at modesfigure 2: an example of actualpower consumption in atsimulation modeHow A Hybrid pLAtforM cAn HELpA hybrid ESL/RTL verification platform can address these limitations by integrating the RTL model of the subsysteminto the ESL base platform, thus replacing the corresponding SystemC implementation. In this configuration, a UVMtestbench is used to convert abstract TLM 2.0 transactions representing bus accesses on the SoC’s bus fabric to pin-level representation on the RTL subsystem interface. The testbench also converts the TLM 2.0 general payloadtransactions into sequences that are passed to the verification IP (VIP) component. On completion of a bus cycle,the VIP returns a response that is passed back to the virtual platform as a TLM 2.0 response.In addition, the ESL CPU model is swapped for a model that provides both a signal and TLM interface. Such hybridarchitecture allows for directly connecting some pin-level signals to the processor at the RTL level. One example isinterrupt signals, which, when connected at the signal level, give better control over interrupt timing critical for theembedded system verification flow. Combining transaction level and RTL models exposes more details abouthardware-software issues than does pure TLM abstraction.Since the hybrid configuration uses a processor model with a mixed TLM/RTL interface, it allows for an accurateswitchable processor as well. The configuration allows for instruction-level accuracy, including fetching instructionsand reading from/writing to memory either with TLM 2.0 transactions or software memory accesses using acoherent memory server implemented as an API connected directly to the instruction set simulator (ISS) of the CPU.In this case, the program and data memory is mapped as optimized accesses. This mechanism reduces the TLM/RTL traffic to I/O communications and allows for visualizing both the number of hardware and software cycles andthe number of executed instructions.figure 4: example of a combinedesl/rtl verification platformfigure 5: a collection of codecoverage dataBy enabling the ability to turning on or off logic simulationtransactions, optimized memory access allows for controllingwhich address spaces need to be mapped to coherent servers.Thus, the ratio between HDL simulation speed and debugvisibility is fully scalable. Cycle-accurate-level simulation is alsopossible when an RTL processor model is used. In this mode,the processor model communicates at the pin-level with otherSoC components. The various processor models make itpossible to dynamically switch simulation accuracy; theswitching mechanism propagates CPU states between ISS/RTLlevels and transfers the contents of caches.The hybrid ESL/RTL platform allows for concurrently observingand debugging hardware and software domains. It does so bylinking the software debugger with the logic simulator, whichgives full visibility of the processor while running the entiredesign in the HDL logic simulator. Since the software debugger is fully synchronizedwith the logic simulator, it’s possible to propagateof four levels of logic into the software’sdebugging environment. This capability allows fordetection of problems that would otherwiseinvisible without four-state logic, such as X statesused in comparisons or computation, or thereferencing of uninitialized memory or registers.figure 6: software execution acceleration mechanismfigure 7: hybrid esl/rtl platformfor hW/sW debuggingfigure 8: arm® 1176 cpU register window showing X states©2011 mentor graphics corporation, all rights reserved. this document contains information that is proprietary to mentor graphics corporation and may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies. in accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. all trademarksmentioned in this document are the trademarks of their respective owners.f o r t h e l a t e s t p r o d u c t i n f o r m a t i o n , c a l l u s o r v i s i t :concLusionIn sum, the hybrid ESL/RTL coverification platform provides the following benefits:■Higher speed compared to pure RTL simulation■Ability to check properties of RTL code using target software running on the CPU■Ability to debug critical timing of software functions at the transactional and pin level■Full visibility of the processor while running the entire design in the HDL logic simulator■Ability to debug the hardware-software interface at a greater level of detail than is possible with an abstractESL model■Multiple levels of accuracy (instruction or cycle-accurate)。
soc 安时积分法 单位
soc 安时积分法单位SOC（System on Chip）是一种集成了多个功能模块的芯片，它将处理器核心、内存、外设接口等关键组件集成在一个芯片上，实现了多种功能的集成化。
安时积分法是一种评估SOC性能的方法，通过对SOC进行全面的测试和评估，以评估其在不同应用场景下的性能表现。
本文将从不同角度介绍SOC安时积分法的相关内容。
一、引言随着科技的飞速发展，SOC已经成为了现代电子设备中不可或缺的核心组件。
为了保证SOC的高质量和高性能，需要对其进行全面的测试和评估。
而安时积分法作为一种常用的评估方法，能够全面、客观地评估SOC的性能。
二、SOC的功能组成SOC通常包含处理器核心、内存、外设接口等关键组件。
处理器核心是SOC的重要组成部分，负责执行指令和控制SOC的运行。
内存用于存储数据和程序，可以分为内部存储器和外部存储器两部分。
外设接口包括各种输入输出接口，如USB接口、以太网口等。
三、安时积分法的原理安时积分法通过对SOC进行全面的测试和评估，以评估其在不同应用场景下的性能表现。
具体步骤如下：1. 确定测试目标：根据SOC的应用领域和性能需求，确定测试目标，包括测试的功能、性能指标等。
2. 编写测试用例：根据测试目标，编写一系列测试用例，覆盖SOC 的各个功能模块和应用场景。
3. 进行测试：将编写好的测试用例加载到SOC中，进行测试。
测试过程中需要记录测试结果和相关数据，例如运行时间、功耗等。
4. 分析测试结果：对测试结果进行分析，评估SOC在不同测试用例下的性能表现。
可以通过绘制曲线图、计算平均值等方式进行分析。
5. 优化和改进：根据测试结果，对SOC进行优化和改进。
可以通过调整硬件设计、优化软件算法等方式来改进SOC的性能。
四、安时积分法的应用场景安时积分法可以应用在各个SOC的开发和测试过程中，以评估SOC 的性能表现。
具体应用场景包括但不限于以下几个方面：1. 嵌入式系统开发：对于嵌入式系统来说，性能和功耗是两个重要的指标。
SOC实验报告范文
SOC实验报告范文一、实验目的1、了解SOC系统的结构和基本内容；2、了解FPGA基本工作原理和内容；3、了解FPGA的基本开发过程5、熟悉FPGA设计实验的软硬件环境，加深对PoleStar实验版的认识，为后面的实验的学习做好准备。
二、实验设备PC主机、某ilin某ISE开发软件、PoleStar实验平台三、实验原理1、SOC嵌入式SOC：是指在嵌入式系统中广泛应用的，有专门应用范围的SOC芯片，是在单个芯片上集成一个完整的系统，对所有或部分必要的电子电路进行包分组的技术。
所谓完整的系统一般包括中央处理器、存储器、以及外围电路等。
具体地说,SoC设计的关键技术主要包括总线架构技术、IP核可复用技术、软硬件协同设计技术、SoC验证技术、可测性设计技术、低功耗设计技术、超深亚微米电路实现技术等,此外还要做嵌入式软件移植、开发研究,是一门跨学科的新兴研究领域。
2、FPGAFPGA（Field－ProgrammableGateArray），即现场可编程门阵列，它是在PAL、GAL、CPLD等可编程器件的基础上进一步发展的产物。
它是作为专用集成电路（ASIC）领域中的一种半定制电路而出现的，既解决了定制电路的不足，又克服了原有可编程器件门电路数有限的缺点。
FPGA具有以下特点：1）采用FPGA设计ASIC电路(特定用途集成电路)，用户不需要投片生产，就能得到合用的芯片。
2）FPGA可做其它全定制或半定制ASIC电路的中试样片。
3）FPGA内部有丰富的触发器和I／O引脚。
4）FPGA是ASIC电路中设计周期最短、开发费用最低、风险最小的器件之一。
5)FPGA采用高速CHMOS工艺，功耗低，可以与CMOS、TTL电平兼容。
可以说，FPGA芯片是小批量系统提高系统集成度、可靠性的最佳选择之一。
FPGA是由存放在片内RAM中的程序来设置其工作状态的，因此，工作时需要对片内的RAM进行编程。
用户可以根据不同的配置模式，采用不同的编程方式。
soc实验报告
Soc设计综合实验报告班级：学号：姓名：指导老师：实验二添加一个IP到系统中【实验介绍】XILINX的EDK9.1的IP Catalog 里提供了大量的免费的IP，包括各种内存控制器IP，通讯类IP等资源。
作为系统设计者只要对这些IP的参数加以配置就可以应用在系统中，大大减少设计工作量。
下面我们就对IP Catalog里GPIO的IP去控制LED的亮和灭和检测按键的输入检测。
【实验目的】1：学会在EDK9.1如何添加IP和配置IP的参数。
2：如何用GPIO的IP控制外设。
【实验器材】PC一台，ISE9.1.03i软件，EDK9.1.02i软件，Xilinx Spartan3E开发板一套。
【实验步骤】1、EDK向导设置的步骤点击击Xilinx Platform Studio后，系统会自动弹出一个对话框，第一。
个选项的是基本系统建立向导，用户请选择这个选项，然后点击OK。
的如下对话框中选择要创建一个新工程。
5. 选择创建工程后，在如下面两个选项里，第一项是选择Xilinx定制的开发板，第二项是选择用户自定制的开发板，在这里我们选择第二项，然后点击Next。
6. 在下图的选项里，选择开发板对应的器件，根据实验的条件，开发板spartan3e，其设置如下，然后点击Next7. 在下图中是软核进行配置，Reference Clock是外部输入的时钟，开发板上配置的是66M 晶振，所以设置为66M，Reset Polarity标签是Microblaze软核复位的方式，由于开发板的复位电路是用电阻上拉为高，用户请选择低复位，在Debug标签里，用户选On-chip H/W DebugModule是硬件调试方式，这种调试方式最常用且调试速度快，在Local Memory标签是对指令和数据的存储空间进行设定，用户在这里选择32K，它占用的是FPGA的Block RAM的资源，然后点击Next。
8、下图对话框主要是设置标准输入和输出设备，推荐用户选择RS232，当用户调试系统时，调试信息将通过RS232打印到上位机，然后点击Next,Memory test 的选项系统自动生成一段应用程序，代码的内容是打印一些信息到超级终端。
系统级芯片集成——SoC
高达数百兆的系统时钟频率以及各模块内和模块间错综复杂的时序关系，给设计带来了多问题，如时序验证、低功耗设计以及信号完整性和电磁干扰、信号串扰等高频效应。
3、系统级芯片多采用深亚微米工艺加工技术，在深亚微米时走线延迟和门延迟相比变得不可勿视，并成为主要因素。
再加之系统级芯片复杂的时序关系，增加了电路中时序匹配的困难。
深亚微米工艺的十分小的线间矩和层间距，线间和层间的信号耦合作用增强，再加之十分高的系统工作频率，电磁干扰、信号串扰现象，给设计验证带来困难。
二、SOC设计技术1、设计再利用数百万门规模的系统级芯片设计，不能一切从头开始，要将设计建立在较高的层次上。
需要更多地采用IP复用技术，只有这样，才能较快地完成设计，保证设计成功，得到价格低的SOC，满足市场需求。
设计再利用是建立在芯核（CORE）基础上的，它是将已经验证的各种超级宏单元模块电路制成芯核，以便以后的设计利用。
芯核通常分为三种，一种称为硬核，具有和特定工艺相连系的物理版图，己被投片测试验证。
可被新设计作为特定的功能模块直接调用。
第二种是软核，是用硬件描述语言或C语言写成，用于功能仿真。
第三种是固核（firmcore），是在软核的基础上开发的，是一种可综合的并带有布局规划的软核。
目前设计复用方法在很大程度上要依靠固核，将RTL级描述结合具体标准单元库进行逻辑综合优化，形成门级网表，再通过布局布线工具最终形成设计所需的硬核。
这种软的RTL综合方法提供一些设计灵活性，可以结合具体应用，适当修改描述，并重新验证，满足具体应用要求。
另外随着工艺技术的发展，也可利用新库重新综合优化。
布局布线、重新验证获得新工艺条件下的硬核。
用这种方法实现设计再利用和传统的模块设计方法相比其效率可以提高2一3倍，因此，0.35微米工艺以前的设计再利用多用这种RTL软核综合方法实现。
随着工艺技术的发展，深亚微米（DSM）使系统级芯片更大更复杂。
这种综合方法将遇到新的问题，因为随着工艺向0．18微米或更小尺寸发展，需要精确处理的不是门延迟而是互连线延迟。
soc测试方法
soc测试方法SOC测试方法是一种用于评估软件系统安全性的方法。
它通过模拟真实攻击场景，测试系统的漏洞和弱点，以确保系统在面临各种威胁时能够保持稳定和安全。
在SOC测试中，首先需要确定测试的目标和范围。
这包括确定测试的系统组件和功能，以及测试的时间和资源限制。
然后，测试团队将根据系统的设计和实现文档，分析系统的安全需求和威胁模型，并制定测试策略和计划。
在测试策略中，测试团队将选择合适的测试方法和技术，以评估系统的安全性。
常用的SOC测试方法包括黑盒测试、白盒测试和灰盒测试。
黑盒测试是在没有系统内部信息的情况下进行的，模拟真实攻击者的行为，测试系统的安全性。
白盒测试则是基于系统的内部信息进行的，测试系统的实现是否符合安全标准和最佳实践。
灰盒测试则结合了黑盒测试和白盒测试的特点，既考虑系统的外部行为，又考虑系统的内部结构和实现。
在具体的SOC测试过程中，测试团队将根据测试策略和计划，执行一系列的测试用例和攻击场景。
测试用例是一组输入和预期输出的组合，用于评估系统的功能和安全性。
攻击场景则是模拟真实攻击者的行为，测试系统的弱点和漏洞。
在测试过程中，测试团队将记录和分析测试结果，并根据结果调整测试策略和计划。
测试结果包括系统的漏洞和弱点，以及相应的修复建议。
测试团队还将评估系统的安全性能和可靠性，以确保系统在面临威胁时能够保持稳定和安全。
SOC测试方法是一种评估软件系统安全性的方法，通过模拟真实攻击场景，测试系统的漏洞和弱点。
它是确保系统安全性的重要手段，可以帮助组织保护其信息资产和业务运行的安全。
通过合理的测试策略和计划，以及准确的评估和分析，SOC测试可以提高系统的安全性，并帮助组织及时发现和修复系统中的安全问题。
集成测试报告
集成测试报告文档编号：项目名称：目录1 引言 (4)1.1 目的 (4)1.2 术诧定义 (4)1.3 参考资料 (5)1.4 限制与约束 (5)2 概述 (5)2.1 测试对象 (5)2.2 测试目的 (6)2.3 测试环境 (6)2.4 测试地点 (7)2.5 测试旪间 (7)3 测试结果及分析 (8)3.1 测试结果 (8)3.2 结果分析 (9)3.3 缺陷说明 (10)4 测试结论 (10)1 引言1.1 目的编写该报告的目的1.2 术语定义集成测试每个模块完成单元测试以后，将所有功能模块集成在一起的测试，以验证各模块的正确性和接口的正确性。
回归测试每次做完测试后进行系统修改后，为防止产生新的BUG，对修改后的部分进行的测试。
风险评估对于集成测试阶段可能产生的风险进行预测，并提早出相应的解决方案，降低风险发生旪对测试所造成的影响。
相互审查小组内成员对其他成员已经测试过的模块进行抽样测试，提高测试效率。
路径覆盖路径覆盖是指某一流程（如注册流程）各个页面之间的跳转路径覆盖。
BigBulbs 小DDPDDP指本阶段发现的BUG数占系统总的可能存在bug数的百分比。
1.3 参考资料编写本报告的参考文档和依据1.4 限制与约束本部分测试主要采用了代码审查，通过对核心源代码的阅读，发现代码中存在的诸如代码格式、逻辑错误等问题；通过对数据流程的分析，编写测试用例，进行动态测试，发现功能上的错误。
2 概述2.1 测试对象本测试主要为XXX系统的集成测试，描述该项目。
测试是网上书城的最终集成测试，是建立在开发组程序员开发完毕以及开发组单元测试完毕的基础之上。
2.2 测试目的在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活劢。
确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。
2.3 测试环境硬件配置测试软件配置：● 操作系统Windows 7/Windows XP SP3/Ubuntu 10 ● 集成开发环境VS2008● 数据库SQL SERVER 2005● 测试工具Selenium/LoadRunner● 浏览器IE7/IE8/Firefox 3.5.22.4 测试地点XXXXX2.5 测试时间XXXXXX3 测试结果及分析3.1 测试结果3.2 结果分析测试用例：注册用户名b12，密码******，并填入用户信息。
SoC系统测试与分析
SoC系统验证方法
• 在实际中对SoC进行验证时，由于它是由多个功 能块组成，可以将SoC的整个系统级测试平台运 用于系统芯片的每一个子模块（功能块），实现 对每个功能块的细节进行验证。
SoC系统验证方法
• 对SoC功能块的细节进行验证时，可以采用如下 多种方法：硬件建模、接口验证、软/硬件协同验 证、随机测试、基于应用程序的验证、门成测试矢量；数据信 号发生器根据计算机的要求产生测试波形，并加载 到被测电路上；逻辑分析仪采集被测电路的响应信 号并进行一定的分析，然后将结果送到计算机中进 行处理。
基于神经网络的电路测试生成 方法
• 人工神经网络（ANN）由于其优良的特性，能较 好的处理目前串行计算机难于解决的NP完全问题
（如Hopfield神经网络用于TSP问题的求解）。 • 根据组合电路测试生成的特点，选用Hopfield神
经网络作为电路建模的基础，用神经网络的能量 函数来表征电路的逻辑特性。
二元判定图BDD
• 二元判定图(BDD)就是一种较有效的方法，它将 布尔函数的功能用有向无环图来表示，图中从根 节点到叶节点的路径对应了布尔函数值为1的一个 输入矢量。
目的是检查行为设计是否满足功能需求。 性能验证：
目的是检查所选出的架构是在满足功能需求之 外是否能满足性能需求。
SoC系统验证方法
在整个验证过程中，都将使用测试平台来检验设 计对象的功能，系统级测试平台是整个验证过 程的一个关键。
SoC系统验证方法
从系统规约中提取出一项 功能要求，并定义出检验 其功能的具体测试，重复 进行，直至为每一项功能 都建立了测试。
SoC系统验证方法
在系统芯片的设计过程中，系统规约确定之后 进行系统级设计。首先对系统行为进行建模，根 据功能规范要求对行为模型进行验证；然后将行 为模型映射到由芯核和功能块组成的架构之上。 目的就是去验证该架构的功能和性能。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
地铁交通6号线自动售检票系统（AFC）SOC系统集成测试用例和记录
编写人员：方亚敏
编写日期：2011.12.22
目录
1用户管理5
1.1用户更改5
1.2用户签退6
1.3用户超时退出7
2SOC监控 8
2.1设备事件信息监控（需详细列出每个终端设备会出现的所有状态）8
2.2设备状态信息监控（需详细列出每个终端设备会出现的所有状态）9
2.3SNC状态监控10
3系统管理11
3.1操作日志11
3.2数据迁移12
3.3时钟同步13
3.4网络诊断14
3.5启动VNC 15
3.6关闭SNC 16
3.7关闭SOC 17
4设备操作18
4.1命令下发18
4.2模式切换24
4.3寄存器查询30
4.4状态查询31
4.5当前参数版本查询 32
4.6将来参数版本查询 34
4.7软件版本查询35
4.83014重新下发36
4.9参数重新下发37
4.10交易数据补发38
4.11软件更新39
4.12图片更新40
4.13系统当前状态41
4.14启动紧急模式42
5数据查询43
5.1BOM签到/签退查询43
5.2操作员查询44
6设备日故障统计45
6.1GATE故障报告统计45
6.2BOM故障报告统计46
6.3TVM故障报告统计47
6.4ISM故障报告统计48
7参数查看（LC下发）与AGM、TVM、BOM相关的参数下发后需增加下发设备端的用例49
7.11041-车站配置49
7.22000-线路部通讯参数50
7.33002-AFC设备运营参数 51
7.43003-TVM运营参数52
7.53004-BOM运营参数53
7.63005-闸机运营参数54
7.73006-车站名称/线路设备表55
7.83007-线路名称表56
7.93008-系统故障代码表57
7.103009-操作员表58
7.113010-线路本地语言资源文件59
7.123011-清分系统本地语言资源文件 60
7.133014-设备节点标识码设置表61
7.143082-站换乘映射关系表62
7.153085-出站换乘站映射关系表63
7.164001-节日表64
7.174002-车票类型表65
7.184003-费率表66
7.194004-区域表67
7.204006-非高峰时刻表68
7.214007-车票黑表-全量69
7.224008-车票黑表-增量70
7.234009-车票类型关系对应表71
7.244015-移动手机票类型关系对应表 72
8报表73
8.1报表73
1用户管理1.1用户更改
1.2用户签退
1.3用户超时退出
2SOC监控
2.1设备事件信息监控（需详细列出每个终端设备会出现的所有
状态）
2.2设备状态信息监控（需详细列出每个终端设备会出现的所有
状态）
2.3SNC状态监控
3系统管理
3.1操作日志
3.2数据导出（导出未发送的中央的SC数据）
3.3数据导入
3.4时钟同步
3.5网络诊断
3.6启动VNC
3.7关闭SNC
3.8关闭SOC
4设备操作
4.1命令下发
4.1.1上传寄存器数据-审计
4.1.2关闭设备
4.1.3打开设备
4.1.4上传设备状态
4.1.5使用主IP通信（保留）
4.1.6使用备用IP通信（保留）
4.2模式切换
4.2.1紧急模式
4.2.2进站出站免检模式
4.2.3日期免检模式
4.2.4时间免检模式
4.2.5列车故障模式
4.2.6超程免检模式
4.3寄存器查询
4.4状态查询
4.5当前参数版本查询
4.6将来参数版本查询
4.7参数同步
4.8软件版本查询
4.93014重新下发
4.10参数重新下发
4.11交易数据补发
4.12软件更新
4.13图片更新
4.14系统当前状态
4.15启动紧急模式
5数据查询
5.1BOM签到/签退查询
5.2操作员查询
6设备日故障统计
6.1GATE故障报告统计
6.2BOM故障报告统计
6.3TVM故障报告统计
6.4ISM故障报告统计
7参数查看（LC下发）与AGM、TVM、BOM相关的参数下发后需增加下发设备端的用例
7.11041-车站配置
7.21041-车站配置-下发
7.32000-线路部通讯参数
7.42000-线路部通讯参数-下发
7.53002-AFC设备运营参数
7.63002-AFC设备运营参数-下发
7.73003-TVM运营参数
7.83003-TVM运营参数-下发
7.93004-BOM运营参数
7.103004-BOM运营参数-下发
7.113005-闸机运营参数
7.123005-闸机运营参数-下发
7.133006-车站名称/线路设备表
7.143006-车站名称/线路设备表-下发
7.153007-线路名称表
7.163007-线路名称表-下发
7.173008-系统故障代码表
7.183008-系统故障代码表-下发
7.193009-操作员表
7.203009-操作员表-下发
7.213010-线路本地语言资源文件
7.223010-线路本地语言资源文件-下发
7.23 3011-清分系统本地语言资源文件
7.243011-清分系统本地语言资源文件-下发
7.25 3014-设备节点标识码设置表。