Tuesday, 25 February 2014 05:57

Using Zigbee to Integrate Medical Devices

Written by

Proceedings of the 29th Annual International

Conference of the IEEE EMBS

Cité Internationale, Lyon, France

August 23-26, 2007.

Using Zigbee to Integrate Medical Devices

Paul Frehill, Desmond Chambers, Cosmin Rotariu

Abstract— Wirelessly enabling Medical Devices such as Vital Signs Monitors, Ventilators and Infusion Pumps allows central data collection. This paper discusses how data from these types of devices can be integrated into hospital systems using wireless sensor networking technology. By integrating devices you are protecting investment and opening up the possibility of networking with similar devices.

In this context we present how Zigbee meets our requirements for bandwidth, power, security and mobility. We have examined the data throughputs for various medical devices, the requirement of data frequency, security of patient data and the logistics of moving patients while connected to devices.

The paper describes a new tested architecture that allows this data to be seamlessly integrated into a User Interface or Healthcare Information System (HIS). The design supports the dynamic addition of new medical devices to the system that were previously unsupported by the system. To achieve this, the hardware design is kept generic and the software interface for different types of medical devices is well defined. These devices can also share the wireless resources with other types of sensors being developed in conjunction on this project such as wireless ECG (Electrocardiogram) and Pulse-Oximetry sensors.

Keywords—Biomedical Telemetry, Medical Devices, Bioinformatics, Wireless Sensor Networks, Healthcare Information Systems.

I. INTRODUCTION

MANY devices that exist today by the bedside in the hospital ward, intensive care unit or other clinical setting have data output features over serial ports and other types of interfaces such as USB. These devices are usually considered a significant investment and are usually purchased in an ad hoc fashion as required when finance becomes available. The consequence of this is that devices are often from different manufacturers that don’t support any standard protocol. This can make integrating these devices into a single network difficult.

In the hospital ward Vital Signs monitors, Ventilators and Infusion Pumps of many different brands are usually portable and wheeled from patient to patient as required. By networking these devices the hospital gains all the advantages associated with storing patient data centrally in electronic records. By making the device part of a wireless sensor network such as a Zigbee [1] network there are several more advantages including, cable replacement, mobility and location management. Once these devices are networked they can also use the infrastructure of other deployments of similar wireless sensor networks in the surrounding environment.

To achieve this type of solution each device must be fitted with a piece of hardware that will act as a serial to wireless bridge, a Medical Device Interface (MDI). This MDI will allow the device to receive and transmit data within the wireless sensor network. This inexpensive hardware will be generic to fit a wide range of medical devices. Similarly the firmware can be kept generic and any specific device communication protocols can be implemented on a server on the network backend.

The work described in this paper is part of a larger project,the goal of which is to provide a complete patient monitoring system. Other features of the overall system will be to provide ECG (Electrocardiogram) and Pulse-Oximetry data in a novel way over a wireless sensor network using expertise gained on prior projects [2].

II. RELATED WORK

The concept of using wireless sensor networks for Medical Care and wireless patient monitoring has been explored by others but integrating data from other devices is generally not discussed. There is ongoing related work in patient monitoring using wireless sensors such as the “CodeBlue”project at Harvard [3]. Others have also proven successful with wireless sensor networks designs for medical sensors [4] and in the management of sensor data [5]. It has been identified that it is desirable to wirelessly enable existing medical devices that provide vital signs data using technologies such as Zigbee [6], [7]. The research described in this paper aspires to meet these requirements. The use of wireless sensor networks within the hospital has been extensively examined. Moreover, other wireless technologies within the same frequency band, such as IEEE 802.11 [8], have existed within the hospital for some time [9].

III. REQUIREMENTS ANALYSIS

A. Wireless Technologies

Established standards for wireless applications, such as Bluetooth [10] and IEEE 802.11, allow high transmission rates, but at the expense of power consumption, application complexity, and cost. Zigbee offers low cost, low power devices that can communicate with each other and the outside world. ZigBee's self-forming and self-healing mesh-network architecture lets data and control messages pass from one node to another by multiple paths. This is particularly useful in a hospital environment where interference from walls, people and general obstacles is a major issue. Zigbee is based upon the IEEE standard 802.15.4 [11] for radio hardware and software specification.

B. Mobility

Zigbee enabled devices support a sleep mode. An off-line node can connect to a network in about 30 ms. Waking up a sleeping node takes about 15 ms, as does accessing a channel and transmitting data. If the requirement is to collect data once a minute the device can be placed in a power saving mode saving significant amounts of energy and increasing the battery life. In sleep mode a zigbee chip can assume as little as 1.0uA [12]. This is particularly important in a medical setting where patients are often on the move while still attached to medical devices.

C. Co-existence

Both Zigbee and IEEE802.11 operate in the license-free industrial scientific medical (ISM) 2.4GHz frequency band.IEEE802.11 is already in widespread use within hospitals which would encourage the adoption of Zigbee solutions in the same environment. However care has to be taken to avoid interference between these 2 neighbouring technologies as described in the paper entitled “Coexistance of IEEE802.15.4 with other systems in the 2.4GHz-ISM-band” [13]. By selecting an appropriate channel, after performing a simple site survey, these problems can be easily avoided.

D. Device Parameters

Typical readings available on a ventilator are Inspiratory Tidal Volume, Expiratory Tidal Volume, O2 concentration,Respiratory Rate, Peak Pressure, Expired Minute Volume and Mean Airway Pressure. The settings on the ventilator are also of interest to medical staff. The most typical settings we’ve chosen are Inspiratory Tidal Volume, Minute Volume, O2 Concentration, I:E Ratio, Breath Duration and Inspiratory Flow.

Similarly we have chosen some common parameters for Vital Signs Monitors. These are Respiratory Rate, Non Invasive Blood Pressure, SPO2 and Temperature. The third device we selected parameters for is the Unfusion Pump. The common parameters we are most interested in here are Volume, Time, Ramp and Occlusion Pressure. Further parameters can be easily added to the system in the future.

E. Bandwidth

For development purposes we analysed a Maquet Servo-I [14] which supports all the ventilator parameters described above. This ventilator works in a command response manner.When initial configuration has taken place 2 commands which are 7 bytes long each will produce 2 responses of 67 bytes each. Therefore even in a multi hop mesh network it is anticipated we would be able to support several of these devices plus other types of devices on the same 802.15.4 channel.

 

 

 

29IEEE EMBS国际程序会议

城市  法国里昂

2007823日至27

应用紫蜂技术将医疗器械一体化

摘要:无线电技术能够使医疗设备,例如生命体征监视器,呼吸设备以及输液泵做到重要数据的收集。这篇论文讨论了使用无线电传感器联网技术使数据从这些形式的医疗设备中被整合到医用系统中。通过集成设备,你可以保护投资和开发网络技术应用到类似设备的可行性。

  在这样的背景下,我们讨论怎样使“紫蜂”技术满足我们对于宽带,能源,安全性和移动性的要求。我们已经检验了各种设备的数据总处理能力,要求的数据频率,病人的安全性数据,以及当流动病人连接到设备后的后勤服务。

  这篇论文描述了一项全新的测试成果,这项成果能够使数据被准确无误的集成到用户界面或者医疗信息系统(HIS.这项设计支持动态的增加新的医疗设备到过去并不支持的系统。为了达到这样的目的,硬件设计被保持原样,软件设计对于不同形式的医疗设备的代码被很好的重新定义。这些设备还可以共享无线电资源,通过其他形式正在开发的传感器,来结合到此项目,例如无线电心电图和脉冲血氧测定传感器。

  关键字:生物医学遥测医疗设备生物信息学无线传感器网络医疗信息系统

引言

当前在医院的病房里,重症监护病房,或者其他的临床设置于病床边的医疗设备都有数据输出功能的串行端口和其他类型的接口,如USB接口。这些设备经常是被认为具有重要意义的投资,而且当资金到位时经常是被作为需求以一种特别流行的方式来购买。这样的结果就是从不同制造商购买的设备不能够支持任何的标准协议。这样就会使整合这些设备到一个信号网络变得困难。

在医院病房有许多不同品牌的生命体征监视器,呼吸设备以及输液泵,从一个病人到另一个病人通常需要有便携性以及可移动性。通过联网这些设备,医院获得了有所的优点,将病人数据集中储存在电子记录。通过使用设备的部分无线电传感器网络,例如“紫蜂”技术网络技术,可以包含更多的优点:电缆更换,移动性和位置管理。一旦这些设备是可以联网的,他们也能够在同一环境中使用其他的基础设施类似无线电传感器。

为了获得这种类型的解决方案,每种设备必须被匹配到一块硬件中,做为一个串行的无限网桥即医疗设备接口。mdi将会允许设备通过无线传感器网络来接受和发送数据。这种低成本的硬件将是通用的,以适用于广泛的医疗设备。类似的固件可以保持通用而且任何特定的设备通信协议能够在服务器上网络上的后端得到执行。

本篇论文描述的工作是大项目中的一部分,其目标是提供完整的病人监护系统。其他功能的整体系统将提供心电图(心电图)和脉冲血氧测定法的数据,通过创新的方式,在无线传感器网络知识获得优先的项目。

二相关工作

使用无线传感器网络的医疗服务和无线病人监测的观念一直被别人探索着,但是将数据从其他装置进行整合通常不被讨论。目前正在进行的有关病人监护仪的工作,例如使用无线传感器如“ CodeBlue ”项目在哈佛大学[ 3 ] 开展。其他人同样也成功地使用无线传感器网络设计的医疗传感器[ 4 ]和管理中的传感器数据[ 5 ] 。它已被确定,这是可取的,通过无线方式使现有的医疗设备,提供生命体征数据,使用的技术,例如ZigBee[ 6 ] [ 7 ] 。本篇论文所描述的研究力图满足这些要求。使用无线传感器网络在医院进行了广泛的审查。此外,其他无线技术在相同频段,如IEEE 802.11标准[ 8 ] ,已经被在医院一段使用时间[ 9 ]

三需求分析

A 无线技术

无线应用的既定标准,如蓝牙[ 10 ]IEEE 802.11,允许高速传输速率,但是代价是牺牲能耗,应用复杂性和成本。ZigBee提供低成本,低功率的设备,可以互相交流和外面的世界。ZigBee的自我形成和自我调整的网络架构让数据和控制信息从一个节点传输到另一个多个路径。这是在特别有用的在医院的墙壁干扰,和一般人的阻碍下,是一个重要问题。ZigBee是基于IEEE标准802.15.4 [ 11 ]无线电的硬件和软件规范。

B 调动

实用ZigBee功能的设备,支持睡眠模式。离线节点可以连接到一个网络中的大约30毫秒。唤醒一个沉睡的节点约需15毫秒,因为没有进入的渠道和传输数据。如果要求是收集数据,那么该设备可以放置在省电模式节省大量的能源和提高电池寿命。在睡眠模式的ZigBee芯片可以承担少1.0uA [ 12 ] 。这一点尤其重要,在医疗环境中,病人往往是在轮椅上移动的时候仍然被连接到医疗设备。

C 角共存

ZigBeeIEEE802.11工作在免许可证的工业科学医疗协会( ISM )的2.4GHz频率频段.IEEE802.11已经广泛使用在医院,医院将鼓励通过ZigBee解决方案促使在同一个环境中使用。但是必须注意,以避免干扰这些本论文所描述的两个相邻的技术文件,题为“共存的IEEE802.15.4与其他系统工作在2.4GHz频带” [ 13 ] 。通过选择一个适当的渠道,在一个简单的现场调查表现,这些问题可以很容易地避免。

D 器件参数

可以在呼吸机进行典型的读数如吸气潮气量,呼气潮气量,氧气浓度,呼吸速率,峰值压力,过期每分通气量和平均气道压。医务人员对于仪器上的通风设备也感兴趣。我们已选择的最典型的设置是吸气潮气量,每分通气量,氧气浓度,I E比值,呼吸时间和吸气流量。同样,我们选择了一些常见的参数,生命体征监测器。这些都是呼吸速率,无创血压,血氧饱和度和温度。第三个器件参数,我们选择的是传感频率泵。我们共同最感兴趣的参数是这里的工作量,时间,接线端扭和闭塞压力。进一步参数可以很容易地在后来添加到系统中。

E 带宽

我们分析了支持所有上述呼吸参数的Maquet Servo-I,发现已达到完善的目的。这种呼吸器工作在命令作反应方式。当初始配置发生改变,7字节长的两个命令,每个生产2答复每个67字节。因此,即使是在一个多跳网状网,我们预期将能够支持一些这类设备加上其他类型的设备工作在同一802.15.4频段。

 

F. Scalability

The ventilator, having the most parameters of the devicesstudied, requires the most bandwidth. Experiments carried outon a CSI Vital Signs Monitor [15] show that 44 bytes of data will produce all the information we are interested in. A BraunInfusion Pump [16] exports 24 bytes of data to produce the 4 parameters we need. For any of the medical devices we are concerned with, the readings are typically only required once aminute in a hospital environment. All these devices have their own alarm mechanisms built in; we are purely providing a means of exporting the data automatically. Theoretically a single Zigbee network could have above and beyond 600 Ventilators as each device only requires less than 1KB of bandwidth per minute. The frequency at which we capture the data is decided upon by the clinical staff themselves. A 1 minute interval is a typical value, however even if they were to require the data every few seconds it is clear the network could still support a large number of devices.

IV. SYSTEM ARCHITECTURE

A. High-Level Architecture

The overall System Architecture consists of a Wireless Personal Area Network (WPAN) and a Local Area Network. The WPAN implemented as a Zigbee network communicates with the LAN via a gateway. This gateway also serves as the WPAN coordinator which is responsible for forming the network. Each medical device has a Zigbee node attached(MDI) which enables data to be transmitted wirelessly to the Gateway and then onto a Server existing on the LAN. See

Fig. 1 below for a graphical representation of this. When an MDI is powered on it automatically joins the network and makes itself known to the Server. A user can then associate

this device with a patient using a GUI client. Once an association has been completed the MDI will be notified to begin transmitting data. Data received by the server will be stored in the Electronic Health Record (EHR) for that patient and displayed on any GUI Client that is subscribed.

 

Figure 1. High-Level Architecture

B. Medical Device Interface

The diagram in Fig. 2 below shows the key components of the MDI. The hardware comprises of a Zigbee module, a microcontroller and an RS 232 Interface. The microcontroller is responsible for interfacing with both the RS232 Interface and the Zigbee module.

 

Figure 2. MDI Block Diagram

When the MDI is powered on, the Zigbee stack will automatically join a Zigbee network within range. Next the MDI will announce an ID which is also visible on the external surface of the device. This is done using a protocol we designed for this project. The protocol supports these types of status messages in addition to supporting the actual real data we are interested in. At this point it is possible to make an association with the MDI. To achieve this, the administrator

selects the ID from an automatically generated list on screen, a patient demographic and a type of medical device which is supported in the system. This process results in the server sending the correct RS232 settings to the MDI for the medical device that it is connected to. Now that the system can communicate directly with the medical device the server will send any necessary commands to initiate a data stream from the device.

C. Server Functionality

The server is responsible for decoding specific medical device data. This functionality is implemented in a DLL (Dynamic Link Library) that is run on the server. There is one

DLL for each type of medical device the system supports which allows for future medical devices to be supported without upgrading the server software. Any future device can easily be supported within the DLL framework by simply inheriting from the appropriate class for that particular type of device. These DLLs are loaded at run-time and have a standard interface that each designer must adhere to in order to interoperate with the system. A designer must also complete an XML file from a template to indicate which features the new medical device supports. The DLL only handles device specific information; the main server application decodes this information from our project protocol.

 

Figure 3. New Data Request

When the DLL is loaded by the server application it will receive a value to represent how frequently the server wants GUI data. This value is used to create the interval timer represented in the above UML diagram. When this timer expires the DLL will check the current state it has for the ventilator. Fig. 3 above shows an activity diagram representing a sequence of events surrounding this timer expiration in a DLL for a ventilator. When the timer expires the DLL retrieves the command in the form of a byte array of ASCII characters. Next the DLL raises an event containing the byte array. The server application accepts this event through its event handler, encodes it in our protocol and sends it to the medical device.

Figure 4. Handling New Data

When the medical device returns a response to the server application this data is passed to the DLL as shown in Fig. 4 above. If the DLL does not receive any data within a specified timeout period the DLL will re-initiate communication with the medical device. Data that is received by the DLL is checked to see if it is consistent with the format expected and that the checksum is valid if applicable. Once the data is proven to be valid, a generic data structure that is shared

between the server application and clients is populated. Finally the DLL will raise another event, this time to indicate that GUI data is available. The server then multicasts the new data to any client that is subscribed to that address. The Server could be extended to integrate with existing

hospital systems using HL7 [17] or another uniform interface that is designed specifically for wireless sensor networks could be used such as that developed by DERI [18].

V. LABORATORY RESULTS

The architecture described here has been implemented and tested successfully in a laboratory environment. For this purpose we connected the MDI to a PC simulator designed to act as a Maquet Servo-i ventilator. The Maquet ventilator can return breath readings and settings. To capture these, the SDADB and SDADS Maquet commands are sent to specify which breath readings and settings we wish to retrieve. Then by sending the RADAB and RADAS commands periodically we can capture up to date information from the ventilator.Fig. 6 shows the simulator handling these commands at runtime.

 

Figure 6. Ventilator Simulator

As described in the Architecture the Server DLL maintains a state for each end device so it knows what information to expect in return. In our experiments we successfully retrieved ventilator data at 5 second intervals. We have designed a GUI client which we successfully subscribed to receive this ventilator data. We are collaborating with a local hospital that use the Maquet ventilator and their requirement is data collection at 1 minute intervals. These results are very positive prior to usability tests in the hospital with the actual ventilator. We also performed a limited amount of range testing in the laboratory. We achieved a range of 20m within the confines of the laboratory which would equate to the maximum distance between an end device and a router in the hospital. In addition we carried out some mobility testing by moving the MDI during operation which did not result in any packet loss. Initial results are positive but further extensive testing is needed which will be performed in the hospital environment.

VI. CONCLUSION

In this paper we have shown that a Wireless Sensor Network is a suitable means for capturing data from a medical device. We have discussed how Zigbee meets our requirements in terms of data throughput, power and mobility. Moreover, using this technology we can develop a low cost, scalable solution for a wide range of medical devices. In addition we have an infrastructure that allows us to easily support new devices within the system as needed. This architecture facilitates moving the device data to third party systems and to our own User Interface. We hope that our field trials will result in positive feedback from the clinical staff.

 F.可测量性

通风设备,拥有最多的装置参数研究,需要最多带宽。实验进行在CSI的生命体征监测[ 15 ]表明,44字节数据将产生的所有我们感兴趣的信息。A Braun输液泵[16]出口24字节的数据,以产生4我们需要的参数。对任何我们正关心的医疗设备,典型的数据通常只需要一分钟一次在医院环境。所有这些设备都自己建造的报警机制;我们完全提供了一个输出数据自动的方法。理论上1个单一的ZigBee网络可以有超越600个通风机当每个设备只需要每分钟不到1KB的带宽时。我们捕捉的频率数据被临床工作人员本身所决定。A1分钟的间隔是一个典型的价值,然而即使他们被需要的数据每隔几秒钟,很明显网络

仍可以支持大量的设备。

.系统架构

A.高级架构

整个系统的体系结构由一个无线个人网(WPAN)和局域网组成。该WPAN的实施作为一个ZigBee网络通信用局域网通过一个网关。该网关还担任WPAN的协调员,负责组建网络。每个医疗设备有一个附加的ZigBee节点(磁航向指示器),使数据传送无线网关,然后到一个服务器上的现有局域网。看到图1所示的图形代表了这一点。当MDI供电时,它会自动加入网络和让自己被服务器知道。用户可以然后准这个装置与病人使用一个GUI客户端。一旦协会已经被完成MDI将通知开始传输数据。收到的数据通过服务器为病人将被储存在电子医疗记录(EHR)并显示在被预定的任何GUI客户端。 

1 高级架构

B.医疗设备接口

2中的表显示MDI的关键组成部分。硬件由ZigBee模块组成,一个微控制器和一个RS232接口。微控制器负责为RS232接口和ZigBee模块接口。

 

2 MDI方框图

MDI供电时,ZigBee协议栈自动加入ZigBee网络范围内。下一步的MDI将公布的ID这也是明显的在装置的外部表面上。这是我们使用的为这一项目设计的协议。该协议支持这些状态消息的类型除了支持我们感兴趣的实际的真实数据。在这一点上和MDI做一个结合是可能的。要做到这一点,管理员选择编号从在屏幕上自动生成的列表,一个病人人口和一类在系统中被支持的医疗器械。这一过程的结果是服务器发送正确的RS232串口设置到MDI为被连接到的医疗设备。现在,该系统能直接与医疗设备通信服务器将发出任何必要的命令,以从装置中启动一个数据流。

C.服务器功能

服务器负责解码具体的医疗设备数据。此功能是执行在DLL(动态链接库)中,它是在服务器上运行的。有一个DLL为每一类医疗设备系统支持允许今后的医疗设备以被没有升级的服务器软件支持。今后的任何设备可以很容易被支持在DLL框架内通过简单继承相应的类为特定类型的设备。这些DLL被加载在运行时而且有一个每个设计师必须坚持的标准接口,为了和系统互操作。设计人员还必须完成一个XML文件从模板来说明新的医疗设备支持的功能。该DLL只处理装置具体的信息;主要的服务器应用程序从我们的项目协议解码本信息。

 

3 新的数据请求

DLL被服务器应用程序加载它将收到一个值来代表频率服务器想要的图形数据。此值是用于创建间隔计时器代表在上述的UML图中。当这个计时器终止DLL将检查的现状已经为呼吸机。图3段显示的动态图代表一个事件序列围绕这一计时器到期的DLL中的呼吸机。当计时器终止DLL的检索命令的一个字节数组的ASCII字符的形式,。下一步该DLL引起一个事件包含字节数组。服务器应用程序接受此事件通过它的事件处理,它在我们的协议中编码且传送它到医疗设备。

4 处理新数据

当医疗设备返回一个响应服务器应用这些数据传递到DLL如图4上所示。如果DLL在一个特定

超时时间段内未收到任何数据DLL将重新启动与医疗设备的通信。被DLL接收的数据被检查来看它是否符合预期的格式和有效的校验和是否适用。一旦数据被证明是有效的,通用的被共享在服务器应用和客户之间的数据结构被填充。最后DLL会提高另一种情况,本次说明该图形数据是可用的。然后服务器组播新的数据对任何被认购到该地址的客户端。服务器可以扩大到与现有医院系统使用HL7的标准[17]或其他统一专为无线传感器网络的接口可用于诸如制定DERI[18]

 

 

.化验结果

此架构所述的已被实施和测试非常成功在实验室环境中。为此目的我们连接MDIPC模拟器设计作为Maquet伺服系统呼吸器。该Maquet呼吸器可以返回呼吸读数和设置。为了获取这些,该SDADBSDADS Maquet指令发送到指定的我们希望检索的呼吸读数和设置。然后通过定时地发送RADABRADAS命令

我们可以捕捉最新的信息从呼吸器。图 6显示在运行时间模拟器处理这些命令

 

6 呼吸机模拟器

像架构中描述的服务器DLL保持一种状态为每个终端设备,以便它知道什么信息预期的回报。在我们的实验中,我们成功地检索呼吸机的数据在5秒的间隔。我们已经设计了一个图形用户界面客户是我们成功认购收到此呼吸机的数据。我们正与当地一家使用Maquet呼吸机的医院合作,他们的要求是数据收集在1分钟的间隔。这些结果是非常确切的先于在医院用实际呼吸机的可用性测试之前。我们还在实验室进行了有限的数量范围测试。我们取得了20米内的实验室范围将等于在医院在终端设备和路由器之间的最大传输距离。此外,我们进行了一些流动性测试移动的MDI在操作过程中没有造成任何包的丢失。初步结果是确切的,但进一步深入测试是需要在医院的环境中进行的。

.结论

在本文中,我们已经表明无线传感器网络是一个合适的从医疗设备中获取数据的手段。我们已经讨论了从数据吞吐量、功耗和移动性方面如何使ZigBee满足我们的要求。此外,利用这一技术我们可以制定一个为广泛的医疗设备提供的低成本的、可扩展的解决方案。此外,我们有基础设施使我们能够很容易地提供新的设备系统内的需要。这个架构有利于移动设备的数据给第三方的系统和我们自己的用户界面。我们希望我们的领域测试将产生积极的反馈从临床工作人员那里。

 

 

 

 

Saturday, 30 March 2013 08:32

计算机翻译之基本技巧

Written by

计算机翻译之基本技巧

Thursday, 07 March 2013 10:57

信息产业软件本地化常用术语大全

Written by

软件本地化行业有很多经常使用的行业术语,非行业人士或刚刚进入该行业的新人,常常对这些术语感到困惑。另外,软件本地化行业属于信息行业,随着信息技术的迅速发展,不断产生新的术语,所以,即使有多年本地化行业经验的专业人士,也需要跟踪和学习这些新的术语。

本文列举最常用的本地化术语,其中一些也大量用在普通信息技术行业。对这些常用的术语,进行简明的解释,给出对应的英文。

热键(hot key)。菜单命令和对话框选项中带有下划线的字母或数字。通过按下Alt键和下划线的字母或数字,可以机或命令和选项。

超文本标示语言(Hypertext Markup Language)SGML语言的子集。定义了一组标示符控制页面内容的显示方式。

输入方法编辑器(Input Method Editor-IME)。通过按下键盘的多个键完成输入本地化文字的应用工具。对于汉字,常用的有微软拼音输入法,标准输入法,五笔字形输入法等。

国际化(internationalization-i18n)。在程序设计和文档开发过程中,功能和代码设计能处理多种语言和文化传统,使创建不同语言版本时,不需要重新设计源程序代码的软件工程方法。

国际化测试(international testing)。软件国际化的支持和可本地化能力的测试方法。

日文汉字(Kanji)。来自汉字的单个日文字,有些与当前的汉字书写完全相同,但按照日文发音。

启动会议(kick-off meeting)。新的本地化项目正式开始前的会议,一般由原软件开发商和本地化服务商中的项目组主要代表人员参加。主要讨论项目计划,各方责任,提交结果,联系方式等与项目紧密相关的内容。

分层图像(layered graphic)。为了便于翻译,可以翻译的文字单独存放在文字层的图像。

重复利用(leverage)。在翻译/本地化过程中,以前已经翻译的内容再利用和循环使用的方法。

语言测试(linguistic testing)。对本地化的产品执行与语言有关的内容的测试活动。

本地化行业标准组织(Localization Industry Standard Association-LISA)1990年在瑞士成立,成为本地化和国际化行业的首要协会,目前已经加入的会员超过400多家。LISA的目标是促进本地化和国际化行业的发展,提供机制和服务,使公司间能够交换和共享与本地化、国际化和相关主体相关的流程、工具、技术和商务模型信息。

本地化(localization-l10n)。将一个产品按特定国家/地区或语言市场的需要进行加工,使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。

本地化工具包(localization kit)。由软件开发商提供的包好文件、工具和指导文档的系列文件集。本地化项目开始前,软件开发商提供给本地化服务商。

本地化测试(localization testing)。对本地化的软件进行语言和用户界面测试,以保证软件本地化质量的活动。

本地化服务商(localization vendor)。提供本地化服务的机构,包含软件翻译、软件工程、测试和项目管理等活动。

机器翻译(machine translation-MT)。利用术语表、语法和句法等技术,自动实现从一种人类语言到另一种语言的翻译的方法和技术。

标识语言(markup language)。与文字结合的标识和标签集合,应用程序(例如HTML网页浏览器)将处理这些标识并以正确的形式显示出来。

多字节字符集(multi-byte character set)。每个字符用单个字节或两个字节表示的字符集。

多语言服务商(multi-language vendor-MLV)。提供多种语言软件本地化能力的服务商。大多数多语言服务商主要集中在多语言项目的项目管理上,它们在全球范围内由多个分公司和合作伙伴。

国家语言支持(national language support-NLS)。允许用户设置区域等软件功能。识别用户使用的语言、日期和时间格式等信息。也包括支持键盘布局和特定语言的字体。

外包(outsourcing)。对软件本地化而言,将某些本地化任务交付给第三方的活动。源软件开发商将软件本地化项目交付给本地化服务商,很多本地化服务商,将翻译工作交给自由翻译人员。

便携式文档格式(Portable Document Format-PDF)。由Adobe公司开发的基于PostScript标准的文件格式。PDF文件可以由其他软件创建,主要用于电子文档的发布。

伪翻译(pseudo translation)。将软件中的可以翻译的字符串用长的本地化的字符代替的自动或手工处理的过程,主要用于发现编译和执行本地化文件时潜在的问题。

质量保证(quality assurance-QA)。保证最终产品质量的步骤和流程。

报价单(Request for quotation-RFQ)。软件开发商发送给本地化服务商的包含项目内容和报价的报价单。

投入回报率(Return of Investment-ROI)。判别项目投入费用和受益回报的指标。

调整(resizing)。调整翻译后的对话框的元素,如按钮、列表框、静态控件等的大小和位置,保证翻译后的字符的显示完整和美观。

资源动态链接库(Resource-only .dll )。包含可以本地化的资源,例如,菜单、对话框、图标、屏幕提示字符的动态链接库。

屏幕捕捉(screen capture, screenshot)。使用图像截取软件截获菜单和对话框等软件界面的过程。

Thursday, 07 March 2013 10:53

做好游戏本地化的14个技巧

Written by

想要扩大用户群?将游戏产品本地化以适应目标市场是一个极好的办法。下面我们提供一些顺利完成游戏本地化的技巧。

译前准备

找一个不错的、讲英语的剧本写作员

如果游戏内容需要翻译成好几种语言,最好使用英语作为原文资料,因为几乎所有的译员都接受以英语为原文的翻译。如果原文资料不是英语的,可以先将其翻译成英语,然后才转译到你的目标语言。在本地化过程中总是存在误解蔓延的风险,因此从最开始就采用一位不错的、讲英语的剧本写作员有助于避免这类问题的发生。

在发送翻译之前先审校剧本

英语剧本是其它所有翻译的原文,因此有必要事先对它作全面的审校。审校包括拼写检查和语法检查,检查术语是否一致、注释是否恰当、有无可能造成的误解以及在其它语言中不能引人发笑的笑话。

使用一致的角色名/场景名/物件名/界面名

保证对话、屏幕文本和手册中术语的一致性是非常重要的。它可以保证统一性,方便翻译并有助于避免出现误解。

语言特有的笑话翻译效果不好

翻译笑话从来都不轻松,遇到有双关语/俏皮话以及其它语言特有的笑话或出处时尤其如此。因此,如有可能,避免出现这类笑话——否则,至少记住你得让每个笑话都引得所有目标语用户哈哈大笑!

检查台词长度

如果游戏为某句台词设置了最大字符数,请告知译员。尽管用原文表述的这句台词可能不会超过最大长度,但是在译文中很可能就会超过,因为即使表达同一个意思,有些语言就是用词更多。还要注意对话中的台词是否有最长限时。

原文错误将按目标语言数量倍增

原文剧本中出现的任何错误都会在需要本地化的所有目标语言中反映出来。因此,在发送翻译之前确保原文资料准确无误肯定是一个好主意!

协助译员

译员可能没见过游戏

记住:译员可能没有见过真实的游戏。因此给特定台词(在单独的一列中)添加尽可能多的信息以帮助译员在恰当语境中更好地理解台词。如有可能,提供一个游戏的测试版,这样译员可以在正确的语境中看到台词。

提供指引

如上所述,提供游戏的测试版可以帮助译员理解资料的正确语境。假如你不能提供测试版,有可能的话提供物件/人物的图像和描述。截图也是使译员对上下文产生直观感觉的一个好办法。

正式还是非正式?

在有些语言中,正式的称呼和口吻与非正式的差别很大。你所希望的目标风格并不总是能在原文资料中一目了然地体现出来,因此让译员或翻译公司知道你想要何种风格。

在本地化过程中

较大批量地提交更改

如果在翻译进行的同时原文资料总是在不断更新(不建议这么做,但是有时不可避免),较大批量地提交对原文资料的更改或更新可以保持较低的翻译成本。

对于单独的翻译批量:创建一个术语列表

如果屏幕文本、玩家手册、对话、包装不是一次性全部发送翻译,做一个常用物件/场地/措辞的术语列表是不错的主意。在第一轮翻译过程中,译员确定术语列表中术语的译文。在后续的翻译中,这个列表可以用作参考资料。这样做可以确保译文中术语的一致性。

声音表演小贴士

使用模拟发声

将英语模拟发声录下来可以帮助你了解游戏中的对话是如何进行的。使用模拟发声还可以使你确保对话中的某句台词表达恰当。在找来配音演员之前,将这些记录下来——当配音演员开始念台词录音时,批准通过的模拟发声可以作为一个指导。

为你的剧本添加感叹台词

为了让游戏角色生动起来,给每个角色添加一些感叹台词常常是一个不错的办法——即使你起初可能觉得根本不需要它们。给这些额外的台词录音并不会增加多少开支——但是如果后来你才决定把它们添加进去,可能不仅花费更多,也更耗时,如果你要再次找配音演员来给这些额外的台词录音的话。

维持角色

为确保未来作品中的一致性,最好记录下你给当前作品使用的配音演员。这可以保证同一角色的声音在所有产品中听起来都一样。

Thursday, 07 March 2013 10:50

技巧:感悟本地化翻译的晦涩与简单

Written by

  有人说,本地化翻译项目不好做,一些内容晦涩难懂,而且规矩太多,忙在应付规范上的时间不比做翻译的时间还要少;也有人说,本地化翻译项目很好做,有些项目直接敲字就可以了,瓶颈在于打字速度。其实,这两种说法都一定程度反映了本地化项目的特点和存在的问题。

  本地化的内容晦涩难懂?

  大多是针对初入门者或非理工类出身的翻译人员而言的。这里并不是说本地化这类技术翻译必须要有理工类的背景,而是强调技术知识对于本地化翻译的重要性。当然,翻译任何内容都需要一定的知识面,可能来自社会,来自生活,或者是个人学习的结果,只不过,合格的本地化翻译在专业知识方面要求会更高一些,需要个人不断的学习和积累。笔者有个朋友是英语专业出身,算是文科了,从事本地化后,他系统地自学了计算机基础知识、编程语言、计算机网络等很多内容,现在是非常出色的资深本地化翻译。

  本地化翻译的规矩太多?

  软件本地化翻译的需求最初来源于软件的本地化需要,所以自然就会借鉴很多软件工程的项目管理方式和经验,再加上软件本地化在美国和欧洲做的比较早,他们的语言之间具有近似性,这两个特点促成制定了很多软件本地化的流程规范和翻译规范。具体到翻译层面,项目中会有很多 style guide 内容,新手适应这些规范需要一定的时间,而要从事这个领域的翻译,就必须要了解这些规范。很多项目字数可能不多,而需要阅读的 style guide 内容可能会有上百页。当然对于老手,可以凭借经验则其要点,而对于新手,需要一个适应过程。

另一方面,规矩多多,对于翻译这项创意性的工作也是一种束缚,有的时候甚至会扼杀创造性,妨碍翻译内容的准确表达,让翻译工作和翻译内容都索然无味。这也就需要大家有“带着脚铐跳舞”的心理准备,遵守规范的同时要掌握一个度 —— 遵守规范和翻译标准是第一位,在这个基础上再尽量寻求灵活性。

  本地化项目“简单”?

  有句老话“难者不会,会者不难”,如果译者的计算机知识还不错,对规范比较了解,英语也不差,翻译一般的文档当然是没有问题,有的文档确实就是只需敲字而无需过脑,因为其内容可能已烂熟于胸了。不过,小处也可以见功夫。以常见的软件使用指南中的操作步骤为例,可以说比较简单,但是要真正翻译得准确流畅,让读者清楚明了,还是需要下一点功夫。

  这里要强调的就是,本地化翻译的一个通病在于翻译时缺少上下文连贯性,看似简单的翻译,如果不注意前后的衔接,也可能让读者不知所云。这可能是拜 Trados 断句之所赐,但也体现了翻译人员不注重上下文的问题。任何简单的工作都有出彩之处,扫地也可以扫出花来。翻译更是如此,没有最好,只有更好。当然翻译公司大多并不会注重你的“更好”,你只需合乎规范就可以了,正如版主 thinkcell 曾经的经典评论:“本地化翻译是不求有功,但求无过”,这是题外话了,暂且不谈。

  结论

  一个合格的软件本地化翻译,需要掌握一定的 IT 知识;需要熟悉各种规范,能快速适应新的规范;翻译过程中能够注重上下文的连贯性,需要有点钻牛角尖的专业精神;当然,英文和中文表达也要足够好。