Ocit-O Protokoll v3.0 A01.de - Es PDF

Interfaz de comunicación abierta de Tráfico Sistemas de Control
Las interfaces abiertas para la ingeniería de tráfico
normas y protocolos OCIT
estaciones remotas
OCIT O_Protokoll_V3.0_A01
OC IT De veloper G rupo (ODG)
OCIT ® es una marca comercial registrada de la compañía AVT Stoye, Siemens y Stührenberg SWARCO
OCIT estaciones remotas
Normas y protocolos
Documento: OCIT O_Protokoll_V3.0_A01
Editorial: OCIT desarrollador Group (ODG)
Contacto: www.ocit.org
derechos de autor • 2018 ODG. Sujeto a cambios. Los documentos con la versión o versiones de reciente reemplazan todos los
contenidos de las versiones anteriores.
OCIT O_Protokoll_V3.0_A01 Página 2 de 67

contenido
Especificaciones ................................................. .................................................. ........ 7
1 Introducción ................................................ .................................................. .......... 8
1.1 Límites del sistema ................................................ .............................................. 8
2 interfaces y las funciones del sistema OCIT estaciones remotas ....................................... 9
2.1 Nivel central ............................................... ............................................. 10
transferencia y protocolo 2.2 Datos .............................................. .................... 10
2.3 Los dispositivos de campo ................................................ .................................................. 11 ..
3 modelo de comunicación OCIT estaciones remotas ............................................. ............ 12
3,1 asegurar la transmisión .............................................. ............................ 13
3.1.1 Algoritmo de seguridad .............................................. ...................... 13
3.1.2 Firewall .............................................. .............................................. 13
3.2 direcciones ................................................ .................................................. .... 14
3.3 red IP .............................................. .................................................. ......... 14
3.4 Rutas ................................................ .................................................. ....... 14
3.5 El tiempo ................................................ ................................................ 14
3.5.1 Hora del sistema .............................................. ......................................... 15
3.5.1.1 dispositivos de campo con conexiones de datos permanentes en el panel de control ....... 15
3.5.1.2 dispositivos de campo con conexiones intermitentes a la central 15 ...................
3.5.2 transmisión orientado a Event-............................................. ......... 16
3.5.3 Asignación de tiempo ............................................. ............................ 16
3.5.4 Tiempo de respuesta .............................................. ..................................... 16
3,6 asignación lógica ............................................... ..................................... 16
3,7 perturbar el equipo de transmisión .............................................. ............ 16
4 protocolos de transmisión ................................................ ...................................... 17
protocolo 4.1 de transmisión de la capa OSI 3 (IP) ........................................ ...... 17

4.2 Uso de la capa OSI 4 protocolos (UDP, TCP) ............................... 17
4.2.1 UDP con retroalimentación ............................................ ........................ 17
4.2.2 UDP sin realimentación ............................................ ..................... 18
4.2.3 TCP con retroalimentación ............................................ ........................ 18
4.2.4 TCP sin realimentación ............................................ ..................... 19
4.2.5 Transmisión de seguridad en el plano de transporte ............................... 19
5 protocolo OCIT estaciones remotas BTPPL (capas OSI 5-7) .................................... 19
5.1 capas de protocolo de paquetes de transporte basadas - BTPPL .......................................... 20
5.1.1 Estructura del telegrama BTPPL: ............................................ .................. 21
5.2 Cliente General de Comunicación - Servidor ............................................ ..... 23
5.2.1 cambiar el nombre de dominio de dispositivos de campo a través de un DNS. 24
5.3 Asignación Temporal (sello de tiempo) ............................................ ................... 24
5.3.1 Tiempo de espera .............................................. ............................................. 25
5,4 asignación lógica ............................................... ..................................... 25
5.5 codificación de los datos .............................................. ...................................... 25
5.6 Objetos ................................................ .................................................. ...... 26
5.6.1 Número miembro ............................................ ................................ 28
5.6.2 Identificación de objetos ............................................... ............... 28
5.6.2.1 Selección de los códigos de retorno (RetCodes) ......................................... ... 29
5.6.3 invalidación de caché DNS .......................................... ...................... 31
5,7 asegurar la transmisión en el protocolo OCIT estaciones remotas ..................... 32
5.7.1 contraseñas OCIT O ........................................... ............................... 32
5.7.1.1 La instalación de un nuevo dispositivo ........................................... .......... 33
5.7.1.2 cambio de OCIT O la contraseña de un dispositivo de campo ........................ 33
5.7.2 Transmisión de seguridad por el algoritmo Fletcher ................ 34
5.7.3 Transmisión de seguridad por el SHA-1 algoritmo ................... 35
5.7.3.1 Determinación de la suma de comprobación ............................................ ....................... 36

5.7.3.2 transmitir una orden ............................................ .................... 36
5.7.3.3 Códigos de retorno utilizados por el protocolo de seguridad ........................ 38
5.8 Examen de la canal TCP ............................................ ................................. 38
6 tipificación ................................................ .................................................. ....... 39
6.1 objetos de interfaz ................................................ .................................... 39
6.1.1 Tipos de datos básicos: ............................................. .............................. 39
6.1.2 elemento meta DECL ............................................. ............................ 41
6.1.3 REFPATH .............................................. ......................................... 41
6.1.3.1 REFPATH_DATA .............................................. .............................. 42
6.1.3.2 EXTENSIBLE .............................................. .................................... 42
6.1.3.3 MINCOUNT MaxCount ............................................. ................... 43
6.1.4 meta MSGPART elemento ............................................. .................... 44
6.1.4.1 cadenas de formato .............................................. ..................................... 44
6.1.5 MÉTODO .............................................. ........................................... 45
6.1.6 Atributos de clase .............................................. ........................... 45
6.1.6.1 MARCO .............................................. .............................................. 46
6.1.6.2 FRAME_DATA .............................................. .................................. 46
6.1.6.3 CATEGORÍA .............................................. ...................................... 46
6.1.6.4 GRADO .............................................. ........................................... 46
6.1.6.5 FORMATO .............................................. ........................................... 46
6.2 definiciones de los datos ................................................ ......................................... 46
6.2.1 archivo OCIT Outstation DTD ........................................ .................... 47
6.2.2 OCIT estaciones remotas archivos de objetos con forma de ...................................... . 47
6.2.3 Estructura de los archivos de tipo .......................................... ..................... 47
6.3 interfaces estándar .............................................. ....................................... 53
6.3.1 System Interface .............................................. ................................ 53
6.3.1.1 Obtener .............................................. .................................................. ... 53

6.3.1.2 Actualización .............................................. ............................................... 54
6.3.1.3 Crear .............................................. ................................................ 54
6.3.1.4 Eliminar .............................................. ................................................ 54
7 ejemplo de mapeo de mensajes XML .......................................... ....... 55
7.1 Tipos, descripción XML ............................................. .............................. 55
7.2 casos ................................................ .................................................. ... 58
7.3 Los telegramas ................................................ ................................................. 58
8 opciones de seguimiento .............................................. ............................................. 62
8.1 archivo de seguimiento .............................................. .................................................. 62 ..
8.2 Rastreo externa ............................................... ............................................ 62
8.2.1 Seguimiento de conexión ............................................ ................................ 62
8.3 Formato de archivo de rastreo binario ............................................. .................................. 63
8.4 estructura de la aplicación ................................................ ............................................ 64

estado de los documentos
estado distribuidor comentario fecha

versión
V3.0_A01 PÚBLICA 15:03:18 OCIT-O V3.0
especificaciones
la OCIT estaciones remotas configuración documento OCIT O KD V3.0 proporciona una visión general de todos
los derechos de autor gestionado por las especificaciones de la ODG y se encarga de versiones y lanzamientos
por:
• especificaciones de apareamiento la interfaz "estaciones remotas OCIT para los controladores de tráfico",
con referencia a las especificaciones OCIT-C que se acompañan,
• da información sobre el uso de los perfiles de transmisión y
• proporciona una visión general de paquetes de especificaciones para las interfaces, por su uso de
la ODG requiere una tarifa mínima es
La situación actual es de www.ocit.org publicada.

1 introducción
El registro de documento OCIT-O contiene las definiciones en las estaciones remotas gama OCIT a seguir
para las interfaces compatibles de realización. El documento describe:
• los límites del sistema,
• el protocolo OCIT estaciones remotas
• y contiene reglas para la definición de objetos.
Las definiciones se aplican a los dispositivos de campo y centros de control.
1.1 Límites del sistema
Una visión general del sistema de OCIT se encuentra en el sistema de documentos OCIT S. En este
documento, sólo el área OCIT estaciones remotas se trata. La zona marcada con OCIT estaciones remotas en
la Figura 1, al mismo tiempo representa el rango de definiciones, por lo tanto los límites del sistema OCIT
estaciones remotas son. Interfaces, que van más allá de los límites del sistema ilustrados no se definen en este
documento.
Un sistema OCITOutstations consiste en una unidad central (nivel central) y los dispositivos de campo
OCITOutstations. Sede y dispositivos de campo se comunican a través de las interfaces OCITOutstations.
Figura 1: estaciones remotas OCIT - Interfaces

estaciones remotas OCIT son interfaces estandarizadas con el alcance entre los dispositivos del centro de
control y de campo:
• Central - Dispositivos de campo

Conexión entre dispositivos maestros y de control para el propósito de control, monitoreo y recopilación de
datos. Los dispositivos de campo son dispositivos de un solo maestro, de ahí su otro lado se ve
lógicamente siempre el centro o una herramienta de servicio en la sede.
• Central - Herramientas de servicio (acceso al sistema central)

Permite la conexión de herramientas de servicio en la sede y también proporciona acceso a los
dispositivos de campo. Para la conexión de herramientas de servicio se utiliza la LAN central. Definiciones
adicionales se pueden encontrar en la base documento OCIT O.
• dispositivo de campo - Herramientas de servicio (Local System Access)

Previsto para la conexión de herramientas de servicio directamente a la unidad de control. Hasta ahora, no se
han tomado disposiciones en el OCIT O.
2 interfaces y funciones del sistema OCITOutstations
La tarea típica de OCIT estaciones remotas es el funcionamiento seguro y seguimiento de los dispositivos
de campo a la distancia, con un reconocimiento inmediato, la respuesta y el tratamiento de errores se lleva
a cabo. conoce a partir de los protocolos TCP e IP de Internet se utiliza para la transmisión segura de
datos entre la sede y los equipos de campo. Por lo tanto, la velocidad de transmisión depende de las rutas
en la red y el volumen de datos. Los tiempos de transmisión, por lo tanto no se pueden predecir en cada
caso individual. Sin embargo, no se manifiestan al operador en general. Este tiempo se tiene en cuenta en
todas las especificaciones. OCIT estaciones remotas pueden ser utilizados como el rápido crecimiento de
oportunidades en la tecnología de las telecomunicaciones y de la red en la carretera y tiene una base
técnica para el futuro. Esto también hace que sea posible adaptar OCITOutstations con el tiempo para
cumplir con los nuevos requisitos y ampliar funcional, el volumen de la expansión no se conoce todavía. A
partir de esto, derivar una demanda: la ruta de transmisión no debe ser cargado con los datos críticos en
el tiempo, con el fin de evitar la congestión futuro en su enfoque.
Este requisito se cumple si las tareas de control de tiempo crítico llevan a cabo en los dispositivos a nivel
local y no pueden fijarse entre la sede y el dispositivo a través de la interfaz. Tales sistemas se denominan
"sistemas distribuidos". Por lo tanto, los dispositivos de campo OCIT estaciones remotas tienen
procesadores que manejan los complejos procesos a nivel local y realizan el procesamiento apropiado.
Los comandos y datos cuando ciertos eventos se muestran en la interfaz OCIT O. , acciones oportunas en
todo el sistema son controlados por tiempo

realizado. Para esto en el servicio central de una sola vez está en su lugar, después de los relojes internos de todo el
dispositivo se mueve de manera que todo el sistema tiene todo el equipo desde una única base de tiempo. Todos los
mensajes y comandos están provistos de una "marca de tiempo", que se clasifica en el tiempo. Además, la
sincronización de "ola verde" por medio de la hora exacta del sistema y no por la sincronización de los comandos de
centro de control.
2.1 Nivel central
Los dispositivos de campo son controlados por un nivel central y monitoreados. El nivel central puede consistir
en varios componentes y subsistemas, que pueden estar ubicados en diferentes lugares. Una función definida
de la unidad de control de señal de luz también requiere una función correspondiente en la sede. Además,
estas unidades están equipadas con la llamada de acceso al sistema central. Herramientas de servicios
también pueden comunicarse desde el centro de control directamente a los dispositivos de campo. El acceso a
la herramienta de servicio a los dispositivos de campo cuasi paralelo a los accesos de la unidad central. La
función más importante es que en el sistema central de acceso permite el suministro a distancia de los
controladores de tráfico.
Para los intercambios, las siguientes propiedades son necesarias para comunicarse con OCIT O:
• Soporte para todas las funciones OCIT estaciones remotas
• Proporcionar una hora exacta del sistema,
• Proporcionar el acceso al sistema central de OCIT estaciones remotas.
transferencia de datos 2.2 y el protocolo
La tecnología de transmisión en estaciones remotas OCIT se basa en el estándar de protocolo de transporte

TCP / IP, que es aplicable independientemente de la transmisión de datos físicos y proporciona conexiones de
datos seguras. Esta norma, por ejemplo, utilizar los servicios comunes de Internet como HTTP, FTP o correo
electrónico.
OCIT tiene su propia definición para el protocolo de transmisión del nivel de usuario que puede coexistir
con los estándares de Internet, el "protocolo de Capa básica paquete de transporte" (BTPPL). BTPPL fue
desarrollado en vista de las veces existentes en las redes urbanas conexiones de los cables de control con
potencia de transmisión reducida. Funciona con una pequeña sobrecarga de datos y por lo tanto hace que
sea posible el uso de estas rutas.
BTPPL proporciona dos canales para el transporte de datos. Un canal de alta prioridad puede ser utilizado para
la conmutación de los comandos y los mensajes en el canal de baja prioridad, los datos remotos pueden ser
suministrados, por ejemplo. La operación es asíncrona. Un remitente puede enviar continuamente nuevos
mensajes y no tiene que esperar a la reacción apropiada después del envío de los telegramas, pero puede
asignar este tiempo después de su llegada. Una parte integral del protocolo es el algoritmo SHA-1, lo que
asegura la protección de contraseña a través de una de 24 bytes, que la

Los mensajes de instrucción entre la sede y el dispositivo de campo no pueden ser manipulados.
BTPPL se puede comunicar a través de diversos medios de transmisión que utilizan TCP / IP. Existen normas y
dispositivos de comunicación, por lo tanto estándar para muchos de estos tipos de comunicación. Ejemplos: DSL,
Ethernet, pública digital de la red telefónica conmutada y operación de líneas arrendadas en redes privadas a través de
módems analógicos.
En el sistema de OCIT algunos de estos procedimientos estándar para la comunicación entre dispositivos de campo y los
paneles de control son adecuados. Las disposiciones correspondientes de OCITStandard se llaman perfiles de transferencia
OCIT. Consisten en declaraciones en relación con las funciones del sistema, tipo de medios de comunicación y equipos de
transmisión, requisitos mínimos de rendimiento de transmisión, las características de administración, entre otros
Con perfiles de transmisión OCIT diferentes controladores de tráfico de diferentes fabricantes pueden
funcionar sin ningún tipo de acuerdos adicionales.
Previamente definidos son:
"Perfil 1 - Perfil de transmisión para conexiones punto a punto sobre canales dedicados de comunicación". La
transferencia tiene lugar aquí CCITT con módems analógicos
V.34 con típicamente 28.800 bps.
"Perfil 3 - Ethernet con DHCP". Estandarizada es la conexión a Ethernet, una tecnología de red de datos
por cable para redes de datos locales que permiten un fácil acceso a diversas redes de comunicación es
posible.
No en perfiles de transmisión estandarizados OCIT se pueden implementar específico del fabricante, pero requieren
cambios de hardware y de software para controladores y paneles de control.
2.3 Dispositivos de campo
Los dispositivos de campo con interfaces OCIT O se llaman dispositivo maestro individual. El mando a
distancia es lógicamente siempre, incluso si esto es "el único centro" de varias partes o componentes del
sistema. que llega de las órdenes centrales, por tanto, siempre se llevan a cabo por los dispositivos de la
misma manera sin distinguir de qué componente del que proceden.
Debido a la sincronización del protocolo OCIT estaciones remotas, los dispositivos de campo se construyen
específicamente para su uso en sistemas de configuración distribuida. tareas de control de tiempo crítico se manejan en
estos sistemas a nivel local en los dispositivos de campo. Por lo tanto, los dispositivos de campo tienen procesadores
que manejan los complejos procesos a nivel local y realizan el procesamiento apropiado.

3 de comunicación remotas modelo OCIT
El modelo de comunicación se basa en el modelo de referencia ISO-OSI. El modelo de referencia ISOOSI

(Organización Internacional de Normalización - interconexión de sistemas abiertos), también llamado el
Modelo OSI o modelo OSI, es una definición abstracta de un modelo, todo tipo de sistemas de energía
(con su aplicación real como de diferentes fabricantes con sus diferentes componentes técnicos, público
proveedores, redes de área local con métodos diferentes de acceso y los protocolos de comunicación,
etc.) a una abierta, es decir, red de comunicaciones mutuamente compatibles se pueden conectar.
Figura 2: Las capas en el modelo de referencia OSI ISO
Diseñado específicamente para OCITOutstations, protocolo de ancho de banda optimizado BTPPL incluye
funciones de los niveles de usuario 5 a 7. Con la excepción de OCITOutstations Protocolo BTPPL sólo se
utilizan protocolos estándar.
TCP / UDP / IP son los protocolos de transporte de los niveles medios 3 y 4. Todos los comandos que son mayores que
4 KB, deben ser transmitidos a través de TCP. TCP es obligatoria para poner en práctica!
UDP y TCP, es posible que varias instalaciones de transmisión se pueden definir para los futuros
requisitos sin la parte principal de los cambios de protocolo. En principio, todos los servicios de medios y
de telecomunicaciones usuales pueden ser conectados a través de las capas 2 y la primera protocolos de
conexión se utilizan de acuerdo con el medio de transmisión a utilizar y el medio de transferencia. En
OCIT se establece el tipo de equipo de transmisión de documentos en el "perfil". ¿Qué interfaz, y que
conecte el fabricante utiliza para conectar estos dispositivos siguen siendo liberarlo.
Para su uso entre la sede y los equipos de campo principalmente de punto a punto de conexiones, por
tanto, se encienden las vías de transmisión dedicados en cuestión, en los semáforos propios tendidos de
cable de los clientes existentes. Por lo tanto, este perfil de transmisión se define como la primera (1 perfil
- perfil de transmisión para las conexiones punto-a-punto sobre vías de transmisión dedicados). Aquí el
protocolo PPP (Point-to-Point) y se utiliza como un dispositivo de transmisión

Módem utiliza. El para hacer coincidir los protocolos en las capas 2 y 1 se muestran en la Figura 2.
3,1 asegurar la transmisión
La copia de seguridad de transferencia se realiza en el plano de transporte, y dependiendo del protocolo en la capa 2 (capa de enlace
de datos).
Desde los centros a menudo están conectados a redes tales como Internet o Intranet, un número indeterminado de
usuarios puede tener acceso. Especialmente con las redes internas, muchos usuarios tienen legítimo El acceso. En
ambos casos, un ataque de "hackers" es posible. Por lo tanto, el control de los dispositivos de campo en el nivel de
usuario tiene dos etapas asegurado en OCIT estaciones remotas Protocolo
3.1.1 Algoritmo de seguridad
En el nivel de aplicación de transferencia se hace entre SHA-1 con y sin garantía:
• comunicaciones no relacionadas con la seguridad, tales como la transmisión segura de visualización de

datos, lo que hace que la gran mayoría de la comunicación (dependiendo del proyecto en algunos casos
más de 95% del volumen de datos), sólo contra los errores de transmisión, aleatorios accidentales y
paquetes UDP equivocadas. Tal seguridad requiere sólo 2 bytes por paquete. La formación de la suma de
comprobación es en el PC con sólo unas pocas instrucciones de montaje por byte transmitido posible
(algoritmo de Fletcher).
• Las comunicaciones relacionadas con la seguridad:
• suministro de los usuarios,
• Comandos de control y comandos con impacto en el comportamiento del sistema
tienen la intención de acceder al SHA-1 algoritmo asegurado.
SHA-1 es una suma de comprobación de seguridad que detecta cualquier transferencia y los descartes no
autorizado. SHA-1 también se utiliza en otros contextos para formar firmas digitales y es reconocido como
un mundo seguro. Para la transmisión asegurar una contraseña separada se requiere ( OCIT O contraseña) la
prueba del interlocutor. La aplicación de este método tiene la ventaja, entre otras cosas que el acceso al
sistema no tiene que ser necesariamente una copia de seguridad por un firewall. El costo de este
procedimiento sostiene basa en el tiempo total de ejecución dentro de límites estrechos, ya que sólo una
muy pequeña parte de la comunicación se asegura de esta manera.
3.1.2 cortafuegos
El algoritmo SHA-1 protege el dispositivo de campo que ignora los comandos no seguras. Si Hacker las
interconexiones entre los dispositivos de campo y el centro eléctricamente

aprovechado, sería una invasión de los componentes del sistema central y en la red de gestión más
posible todavía. Este ataque se puede llevar a cabo por el mal uso de los protocolos de red de las capas 3
y 4. La Fig.
Los fabricantes de Centroamérica ofrecer sus dispositivos de comunicación centrales suelen tener una
protección más o menos elevado de estas intrusiones. redes administrativas son usualmente aseguradas
mediante el uso de servidores de seguridad en varios niveles del sistema.
3.2 direcciones
dispositivos de campo y el centro se comunican a través de direcciones IP. En una red de soporte y, por tanto,
cada dispositivo de campo debe tener una dirección IP única. Principalmente vienen direcciones de autogestión
en cuestión. El uso de direcciones reales pagados a Internet es posible, pero debido a la gran cantidad de
direcciones de Internet requeridos poco realistas. Esta "red de dispositivos de campo" a menudo será una red en
forma de estrella a través de líneas definidas por el usuario. Cada dispositivo tiene un nombre de host único
(véase el párr. 5.2).
3.3 red IP
Es un proyecto específico de determinar si OCIT estaciones remotas y las direcciones de los componentes
centrales se encuentran en una red IP común. Si es necesario, proyecto específico utilice un servidor de seguridad.
La comunicación directa entre los terminales centrales y los dispositivos de campo de ingeniería de tráfico
sobre la red IP se define sólo en el acceso al sistema central.
3.4 rutas
Debido al uso de IP en la capa OSI 3, es técnicamente posible, en principio, para llevar mensajes a "rutas", por
lo que las transmisiones de dispositivo de campo a dispositivo de campo o a otros componentes del sistema.
Con conexiones en forma de estrella mientras que las "rutas" a través del centro, que funciona de forma similar
a una central telefónica tiene lugar aquí. No se han tomado disposiciones para estas funciones.
3.5 Momento
El sistema no está diseñado para transmisiones con el tiempo determinista. La velocidad de transmisión alcanzable
en la red depende del sistema de comunicación y la carga de datos en la red. Por lo tanto, las acciones oportunas
en todo el sistema se llevan a cabo con control de tiempo. Para este propósito, se proporciona en el plano central
de un servicio de tiempo, relojes internos del dispositivo presentado después (en el caso estándar), de modo que
todo el sistema de tener todos los dispositivos en una base de tiempo uniforme. Todos los mensajes y comandos
están provistos de una "marca de tiempo", que se clasifica en el tiempo.

3.5.1 Hora del Sistema
El sistema requiere un tiempo de sistema de concordancia en el panel de control y todos los dispositivos de campo
con una precisión de • 500 ms.
El Centro ofrece a la NTP servicio de tiempo Versión 4 (RFC 5905) que puede ser utilizado por los
dispositivos de control de luz de señal OCIT para sincronizar la hora del dispositivo al tiempo central.
Nota: Están conectados a un centro de control y dispositivo de campo con una versión más pequeña OCIT V3.0 (por
ejemplo, V2.0 o V1.1) conectado centro de servicio de tiempo también la NTP Versión 3 mosto (RCF 1305)
proporcionar o estar configurado de manera que las solicitudes de NTPv3 según la las definiciones de estas versiones
son contestadas.
El método de sincronización compensa los tiempos de transmisión en la red. El servicio de tiempo proporciona una
base de tiempo monótona que no conoce saltos por el horario de verano cambios de formato y sin zona horaria
(GMT). La hora UTC es la base de tiempo interna del sistema. Para la conversión de la información de ubicación,
hora local (zona horaria) y los puntos de cambio para el horario de verano / invierno son necesarios. Estos son
OCIT estaciones remotas que no están definidos se tradujo suministrada por los dispositivos OCIT en sus mensajes
UTC veces a la hora local se lleva a cabo en la sede.
Como un principio servidor NTP se aplica FNº. 0 (FG0) en la oficina central, donde la dirección IP se puede
obtener "búsqueda inversa". La configuración manual de NTPServern es una solución específica para el
proyecto.
3.5.1.1 dispositivos de campo con conexiones de datos permanentes en el centro de control
Es especificada por el operador sin petición explícita, el servicio de hora central tiene la más alta prioridad en la
sincronización de la hora de la hora del dispositivo con la hora central. Relojes en los dispositivos de campo
forman la hora del dispositivo sólo después del encendido o cuando el servicio de hora central no está disponible
durante un tiempo predeterminado por el fabricante.
El servicio de hora NTP se encuentra en el centro de conexiones permanentes tales. B. OCIT O-perfil 1, al menos cada 15
minutos, y consulta inmediatamente después del establecimiento de la conexión.
Opcionalmente, el controlador puede estar configurado por el fabricante de manera que un reloj local forma la
referencia de tiempo priorizada para la unidad de tiempo. El servicio de hora central no o sólo entonces en caso
de fallo del reloj local utilizado. Con esta opción, la hora del sistema uniforme requerido sólo se garantiza si la
referencia de tiempo central para el servicio durante un tiempo pm similares how adquirido en los dispositivos de
control de señales de tráfico.
3.5.1.2 dispositivos de campo con conexiones intermitentes en el centro
Una configuración con un servicio prioritario hora central no tiene sentido aquí como que se requieren
conexiones permanentes. Por lo tanto, los relojes locales se forman en los dispositivos de campo (DCF 77, u
otros sistemas), la referencia de tiempo priorizado para la unidad de tiempo. La hora del sistema uniforme
requerido sólo se garantiza si el

tiempo de referencia central para el servicio durante un tiempo pm similares how adquirido en los dispositivos de control de
señales de tráfico.
3.5.2 transmisión orientado por eventos
• Cada proceso de transmisión se desencadena por un evento (evento):
• cuando el estado de funcionamiento de los cambios de dispositivo (operación, mal funcionamiento, de error),
• cuando un Aggregierungszeitraum ha caducado, o
• cuando se decide por la lógica de dispositivo de que la transferencia se va a realizar.
• La transmisión de eventos puede provenir tanto de la sede y de los dispositivos de campo. Si un

reconocimiento del mensaje transmitido se lleva a cabo o no, o si el mensaje se repite en
ausencia de acuse de recibo, es en función de la definición.
3.5.3 Asignación Temporal
Los datos agregados y zwischengepufferte se transmite con una marca de tiempo. El sello de tiempo es
parte de los datos transmitidos.
3.5.4 Tiempo de respuesta
En las transferencias no reconocidas un tiempo de espera debe ser proporcionada, teniendo en cuenta el tiempo de respuesta
máximo esperado.
3,6 asignación lógica
El protocolo BTPPL utiliza un proceso de llamada asincrónica, que es el llamado programa avanza sin
esperar a la ejecución o un acuse de recibo de la orden. Por lo tanto, las respuestas a los comandos
pueden llegar a tiempo un orden diferente. El mapeo lógico entre comando y respuesta de la llamada
asincrónica - aseguró Responder mecanismo de protocolo BTPPL.
3,7 perturbar el dispositivo de transmisión
El comportamiento del sistema en caso de fallo del dispositivo de transmisión depende del tipo de dispositivo y sistema
de transmisión. especificaciones aplicables a todo el sistema que se encuentran en el documento "base". Definiciones
adicionales se pueden encontrar en los documentos de perfiles de transferencia.

4 protocolos de transmisión
En este capítulo, las capas OSI se describen 3 y 4. La Fig. capas OSI 1 y 2 se dan los perfiles en los
documentos OCIT-O.
protocolo 4.1 de transmisión de la capa OSI 3 (IP)

En la capa de red IP estándar utilizado en todos los casos.
4.2 Uso de la capa OSI 4 protocolos (UDP, TCP)
Nota: Función se ha cambiado en comparación con la versión anterior (nuevo tamaño telegrama)!
Para la comunicación con los dispositivos BTPPL OCIT estaciones remotas de los paquetes TCP o UDP se utiliza en
función del tamaño. Todos los paquetes que son más pequeños de 4 Kbytes pueden ser transmitidos a través de TCP
o UDP; todos los paquetes de más de 4 kilobytes siempre deben ser transmitidos a través de TCP. Ya sea que se
transmite a través de TCP o UDP a través decide la sede. En una solicitud de TCP será respondida a través de TCP,
en una solicitud a través de UDP con UDP.
un objeto OCIT-O se crea para cada elemento de suministro.
la OCIT O existentes son métodos, mensajes de error, etc., están utilizados.
Suministro de objetos con btppl (como un mensaje con prioridad baja Ver también
5.1) de transferencia.
El tamaño del mensaje está limitado a 2 MB en TCP. El dispositivo de campo debe tener una
correspondientemente grande de memoria para almacenar temporalmente un suministro completo (buffer). Para
TCP btppl tamaños de telegramas para ser procesados por hasta 2 megabytes.
4.2.1 UDP con retroalimentación
En una transmisión a través de UDP el número de trabajo (véase 5.1.1) y la dirección del puerto de
transmisión + IP del remitente almacenan enviados por el cliente de cualquier puerto de transmisión del
paquete y para asignar la respuesta. El uso de las garantías número de trabajo que pueden ser somete
desde un puerto transmisor de múltiples comandos, sin la necesidad de esperar a la respuesta de un
comando. En función de la importancia de la orden, el paquete se envía ya sea PNP o PHP.
El paquete es recibido por el servidor y se procesan allí. Para procesar el número de trabajo y la
dirección IP del remitente y el puerto original debe ser amortiguada con el fin de devolver la respuesta. Si
se produce la combinación de números mismo puerto serie / trabajo una vez más durante el proceso, le
corresponde a la puesta en práctica de ignorar este comando, ya sea o trabajar fuera una vez más. Una
vez que se procesa el comando, la respuesta es devuelta al número de trabajo original al puerto original.
cuando

después de que el envío del comando de respuesta con el mismo número de puerto y el mismo trabajo, es
decir, el servidor tiene que procesar el comando. El servidor envía la respuesta (paquete de responder) a
la dirección de la que procede la solicitud (número de trabajo + puerto + dirección IP). Cuando el cliente
recibe el mensaje de respuesta antes de que expire el tiempo de espera (reintento), se repite la solicitud
(repetidamente si es necesario). Sólo si después de un segundo de tiempo de espera (fallo) se devuelve
ninguna respuesta, el comando se devuelve como no hacia arriba. A continuación el comunicante no sabe
si la orden no se llevó a cabo, o el comando se ha llevado a cabo y sólo andaba perdido la respuesta o si
el comando se encuentra todavía en una cola. Es la responsabilidad del proceso de llamada, para repetir el
comando en este caso, o ignorar. Una vez que se devuelve una respuesta o si la prueba de tiempo de
espera, el mensaje se transmite al programa de llamada. Todos los paquetes de respuesta posteriores que
llegan tarde son simplemente ignorados.
Para enviar un paquete de telegramas una "Solicitud" de la respuesta se utiliza el paquete "Responder".
4.2.2 UDP sin realimentación
El mensaje se transmite somete desde cualquier puerto. En función de la importancia de la orden, el

cliente envía el paquete (petición) a cualquiera de la PNP o el servidor PHP.
El paquete es recibido por el servidor y se procesan allí.
A medida que los paquetes sin realimentación, sólo se usan los "Mensajes" de abajo-definidos.
4.2.3 TCP con retroalimentación
Antes de transmitir un paquete a través de TCP, se comprueba si un canal TCP ya está abierto. Si este no
es el caso, se abre un canal TCP. En función de la importancia de la orden, el paquete se envía ya sea
(puerto inferior priorizada) el PNP o PHP (Puerto de alta prioridad). El número de trabajo es transmitido
puesto que se requiere para los servidores y clientes de subprocesos múltiples. El canal permanece abierta,
al menos hasta que llegue la respuesta, o hasta que el tiempo de espera (fallo) se produce. pero tiene que
ser comprobada durante la ejecución de comandos si todavía existe el canal. En caso de fallo del comando
se aborta. El canal se abre de nuevo para el siguiente comando.
La respuesta es enviada de regreso al puerto que se originó la emisión. Durante el procesamiento del
canal permanece abierto. El servidor transmite el número de trabajo de la petición- en el
Respondtelegramm en TCP. Si el servidor no puede transmitir el mensaje de respuesta, se descarta y no
trata de abrir el canal nuevo.
En el puerto de transmisión de que el cliente espera de la respuesta (Respondtelegramm) en los anuncios enviados
comandos (mensaje de solicitud). Si (fallo) sin tiempo de espera después de una

La respuesta se devuelve, se devuelve el comando como fallido al alza.
A continuación el comunicante no sabe si la orden no se llevó a cabo, o el comando se ha llevado a cabo y

sólo andaba perdido la respuesta o si el comando se encuentra todavía en una cola. Es la responsabilidad
del proceso de llamada para repetir el comando en este caso, o ignorar. Una vez que se recibe una
respuesta o si el tiempo de espera ha expirado fallar, se devuelve a la persona que llama. No es necesario
que el canal se cierra después de la ejecución. Sin embargo, tanto el cliente como el servidor deben ser
programados con el fin de responder adecuadamente a la rotura del canal. Para enviar un paquete de
telegramas una "Solicitud" de la respuesta se utiliza el paquete "Responder".
4.2.4 TCP sin realimentación
TCP sin realimentación es posible.
4.2.5 Seguridad de transmisión en el avión de transporte
seguridad en la transmisión de datos se produce contra la corrupción en el avión de transporte sólo para
TCP, UDP, pero no. TCP inicializa, monitores y termina la conexión y asegura que los mensajes llegan.
5 de protocolo OCIT estaciones remotas BTPPL (capas OSI 5-7)
Este capítulo contiene la descripción de las estaciones remotas Protocolo OCIT y más con las definiciones
relacionadas con el protocolo tales. B. algoritmo de seguridad utilizado en OCITOutstations.
Figura 3: protocolos para OCIT estaciones remotas
El protocolo OCIT estaciones remotas en el OSI capas 5-7, que comprende:

• la conexión de la comunicación al SW dispositivo (incl. objetos OCIT) de los respectivos
fabricantes y
desarrollado específicamente para el protocolo OCIT estaciones remotas BTPPL. Esto vincula los objetos en los
sistemas remotos (dispositivos centrales y de campo) por llamadas a métodos. BTPPL hace que este método
llama a partir de telegramas a nivel / TCP / IP UDP. BTPPL utiliza estructuras de telegramas muy compactas.
5.1 capas de protocolo de paquetes de transporte basadas - BTPPL
BTPPL incluye:
• estructura del telegrama

- encabezamiento
- Serialización de los datos (parámetros de llamada de métodos)
- Las sumas de comprobación (Fletcher, SHA-1)
• Secuencia de llamadas a métodos

- Funciones con parámetros de retorno
- Funciones sin parámetros de retorno
• Los métodos para cambiar la contraseña OCIT O.
excluye BTPPL
• los métodos de funcionamiento de las funciones del dispositivo (estos son la aplicación)
• Definiciones para capas OSI debajo de IP y
• Los métodos para almacenar datos.
BTPPL es un protocolo simétrico. Se hace ninguna diferencia fundamental entre un dispositivo de campo y un
centro de control. Todas las unidades que participan son el cliente y el servidor. Por lo tanto, es por el
protocolo fácilmente posible que los dispositivos de campo pueden enviar comandos a otros dispositivos de
campo (tales como el nivel Central).
BTPPL utiliza la llamada. Método asíncrono llama. Aquí, por el protocolo de funciones se llaman (
"métodos") en un dispositivo conectado y ejecutados. Las necesidades de recursos de llamadas a
métodos asíncronos es significativamente más bajo que el método sincrónico llama. La funcionalidad
definible de la interfaz se puede dividir en, "propiedades" y "métodos" "tipo de objeto". La división ha
siguiendo de este modo de fondo: En todos los dispositivos hay una serie de elementos que son más o
menos independiente. En un controlador de señal de luz Son estos planes, por ejemplo, una señal cada
uno con sus propios comandos, puntos, diarios de operación o lógicas VA medición. Cada uno de estos
elementos, aunque no físicamente presente, en el sentido de la programación orientada a objetos, un tipo
particular de un objeto (tipo de objeto). Cada uno de estos objetos se puede abordar de forma individual y
tiene sus propias funciones (métodos), se centra en precisamente este

consulte objeto. Ciertos tipos de objetos tales como planes de señal, hay varios objetos en el dispositivo.
Así que estos objetos se pueden distinguir, cada objeto tiene un nombre preciso (ID de objeto).
OCIT estaciones remotas requiere dos puertos por TCP y UDP: mensajes de baja prioridad se transmiten a
través de un puerto a través de los otros mensajes de prioridad de puerto. Ambos puertos se utilizan para
TCP y UDP. Durante la instalación de los dos puertos están predefinidos:
• mensajes de baja prioridad serán a el puerto 3110 transmitida. El puerto está en lo sucesivo
denominado PNP abreviada.
• mensajes de alta prioridad serán a el puerto 2504 transmitida. El puerto está en lo sucesivo denominado PHP
abreviada.
El puerto de envío se establece siempre libremente. La respuesta se envía de regreso al puerto en el

mismo protocolo que se originó la orden. Si una solicitud a través de UDP se envía y la respuesta es> 4K,
se devuelve un error en respuesta.
5.1.1 Estructura del telegrama BTPPL:
offset Offset + 0 Offset + 1 Offset + 2 Offset + 3
0 BL (MSB) ,,, ,,, BL (LSB)
4 HdrLen T V r r S JobTime (Hi) JobTime (Lo)
8 Contador de Tiempo de Trabajo Contador de Tiempo de Trabajo Miembro (Hola) Miembro (Lo)
12 OTYPE (Hola) OTYPE (Lo) Método (Hola) Método (Lo)
16 ZNR (Hola) ZNR (Lo) FNº (Hola) FNº (Lo)
20 Longitud de la trayectoria: HdrLen-16
4 + HdrLen bloque de parámetros:
Longitud: BL-HdrLen-2 (SHA-1 sin fusible)
Longitud: BL-HdrLen-26 (con protección SHA-1)
BL-22 UTC (MSB) ,,, ,,, UTC (LSB)
BL-18 SHA-1 checksum
BL-14 SHA-1 checksum
Bl-10 SHA-1 checksum
Bl-6 SHA-1 checksum
Bl-2 SHA-1 checksum
Bl + 2 Fletcher (Hola) Fletcher (Lo)

Para las líneas de telegramas, no relacionados con la seguridad-BL-22 a BL-2 están desaparecidos.
Nota:
MSB: byte más significativo (2 ^ 31 ... 2 ^ 24)
LSB: byte menos significativo (2 ^ 7 ... 2 ^ 0)
Los campos tienen los siguientes significados:
nombre significado
BL longitud de bloque. La longitud de bloque sólo se utiliza con TCP. Con UDP, se utiliza la
longitud de bloque del bloque de UDP.
HdrLen Longitud de la cabeza incl. Camino en bytes. Desde la dirección de HdrLen los parámetros
de comandos comienzan. Si no hay camino, HdrLen tiene el valor 16, de lo contrario 16+ < Longitud
de la ruta de entrada en bytes>.
T Tipo del telegrama (Bandera >> 5): 0:

Solicitud (mensajes de comando). 1:
Responder (transmisión de respuesta a comandar tipo de mensajes "Solicitud") 2:
Mensaje (Los mensajes de instrucción sin respuesta)

3..8: reservado
V Versión OCIT estaciones remotas BTPPL ((Bandera >> 3) 3): 0:
OCIT estaciones remotas BTPPL Versión 1
1..3: reservado
r Los bits reservados (siempre 0)
S SHA-1 suma de comprobación (Flag & 0x01): 0:

Sólo la suma de comprobación Fletcher
1: checksum Fletcher y SHA-1 checksum
JobTime Tiempo de trabajo y tiempo de trabajo Count juntos forman el número de trabajo. El
número de trabajo se genera un telegrama de solicitud del emisor y no debe ser
trabajo re-asignado a la respuesta (Responder telegrama). En Respond telegrama se
Contador de tiempo introduce el mismo número. De este modo se puede asignar la Respond. En Mensaje
telegramas de este campo se debe establecer en 0.
miembro el productor que ha definido el número de objetos de Access. Los números

fabricante (números de miembros) son asignados por el ODG
OTYPE objeto
método Número del método dentro de la interfaz
ZNR número del centro. Cada panel de control de un operador debe tener un número
central único.
FNº Número del dispositivo de campo por debajo del centro. Todos los dispositivos que son
controlados desde un centro de control debe, central de lejos uno

nombre significado
tienen nombre único. El centro tiene siempre el campo de los dispositivos serie 0th
camino Objetos que existen más de una vez en un solo dispositivo están claramente definidos. La
longitud de los Pathtyps es diferente. Ellos se pueden derivar de HdrLen inmediatamente.
La ruta de acceso puede tener también una longitud impar.
bloque de Los parámetros de entrada en la solicitud y los bloques de mensaje, en el que los bloques
parámetros responden de la parámetros de salida. En los bloques de Respond, los dos primeros bytes son
siempre la palabra de estado en el que se ha registrado en el resultado de la función. El bloque de
parámetros tiene una longitud diferente. El bloque de parámetros puede tener una longitud impar.
UTC Hora en que se envió el paquete, como un formato sin signo de 32. El campo UTC
sólo se utiliza cuando un mensaje seguro es (es decir, con SHA-1) transmitida.
SHA-1 Suma de comprobación. La suma de control es más de la gama de HdrLen

(offset 0 con UDP, TCP 4) (e incluyendo) UTC formado (LSB) (inclusive).
Descripción detallada en el capítulo 5.7.3.
Fletcher Fletcher suma de comprobación. La suma de control se forma sobre el bloque de
HdrLen (inclusive) hasta el byte antes de la suma de comprobación (inclusive). por lo
tanto, siempre incluye el bloque de parámetros y - si se transmiten - incluyendo el
hash SHA-1. Descripción detallada en la sección 5.7.2.
5.2 Generalidades La comunicación cliente - servidor
Todas las comunicaciones disponibles en el registro se remonta al principio de cliente-servidor, que se

describirá aquí. ¿Qué papel luego tomar cada dispositivo de cada uno se enumeran a continuación.
Cada dispositivo tiene un nombre de host único. El nombre de host se estructura de la siguiente manera:
fg <dispositivo número> .z <número del centro>. <operadores de dominio>
El "ruebenstadt-sv.de" OCIT estaciones remotas LSA 5 en el centro 3 del operador por lo tanto tiene el nombre de
host:
fg5.z3.ruebenstadt-sv.de
En la oficina central, se establece un servidor DNS (Servidor de Nombres), y hay suministros específicos del
proyecto las direcciones IP de los dispositivos de campo. Los OCITOutstations El sistema accede (Nota:
OCIT O V2.0 no se ofrece) utilizaron para determinar la dirección IP del servidor DNS (RFC 1034, RFC
1035, RFC 974, RFC 1912).
La comunicación entre los dispositivos de campo a uno otro implica más de enrutamiento IP (todavía no estandarizados). La
asignación de direcciones IP se lleva a cabo para proyectos específicos.

5.2.1 cambiar el nombre de dominio de dispositivos de campo a través de un DNS
Con esta opción, los cambios de nombres de dominio, el dominio de operador, que por lo general afectan a
todos los dispositivos controladores de tráfico / de campo de un área de control de forma automática. La
propietaria realizó Umversorgung los nombres de dominio de todos los dispositivos de campo en cuestión ya
no es necesario.
Los dispositivos de campo determinan a su nombre de dominio válido a partir de datos que se transmiten a los
dispositivos de campo durante la inicialización del nivel central. Estos datos se definen en los perfiles de transmisión
previamente establecidos. Por lo tanto, el dispositivo de campo recibe ya ha sido
• la dirección IP de los pares centrales,
• la dirección IP del dispositivo de campo (FG dirección IP) y
• dos direcciones de los servidores de nombres de dominio.
Para determinar el nombre de dominio y la eventual modificación del nombre de dominio, el dispositivo de
campo, se ejecuta cada vez que se conecte una búsqueda inversa en DNS (DNS inversa) en la dirección IP y el
FG obtiene a partir de DNS a su nombre de dominio completo (totalmente cualificado nombre de dominio). Esto
está de acuerdo con el protocolo OCIT O:
"Fg <número de dispositivo> .z <número del centro>. <Dominio de operador>"
Así, por ejemplo, fg5.z3.ruebenstadt-sv.de. Esta es la válida para el nombre de dominio del dispositivo de campo del
dominio de operador, en el ejemplo ruebenstadt-sv.de, derivada.
Reconoce el dispositivo de campo un cambio en su nombre de dominio, se actualiza su configuración. Si la

búsqueda inversa falla, el dispositivo de campo conserva su configuración anterior.
Cada nivel de componentes centrales OCIT S deben apoyar a la dirección del DNS de búsqueda inversa de
FG-IP.
5.3 Asignación Temporal (sello de tiempo)
• Los datos agregados se transmite en el momento (sello de tiempo) del inicio del intervalo. El
sello de tiempo no es parte de BTPPL pero el objeto respectivo.
• datos Zwischengepufferte se transmite en el momento (sello de tiempo) cuando se produce el

evento. El sello de tiempo no es parte de BTPPL pero el objeto respectivo.
• El formato de la marca de tiempo UNIX codificación de UTC se establece. La codificación almacena el

número de segundos desde el 1/1/1970 en una variable de 32 bits. Esta codificación es compatible
con los sistemas operativos prácticamente todos, que es compacto y facilita la clasificación de los
acontecimientos. es

para asegurarse de que este formato de hora se desborda en 19/01/2038. Para la comunicación en OCIT
estaciones remotas la variable de 32 bits simplemente será numerado en este caso y por lo tanto sólo se ejecuta
sobre 2100 AD. aproximadamente.
5.3.1 tiempo de espera
Nota: Función se ha cambiado en comparación con la versión anterior (nueva regla de cálculo para el tiempo de espera)!
En las transferencias no reconocidas se debe proporcionar un tiempo de espera de la solicitud, teniendo en cuenta el
tiempo de respuesta máximo esperado. Para todas las transmisiones reconocido del mismo intervalo de tiempo:
120 s + longitudes de telegrama / ( n Bytes / s) utilizado.
n = 1000 bytes / s para el perfil 1
longitud del telegrama = longitud de la solicitud + la longitud del telegrama Respond, cada uno de hasta e
incluyendo HdrLen Fletcher.
El tiempo de tiempo de espera se cuenta sólo desde el inicio de la transmisión (iniciar la entrega de la solicitud telegrama a
TCP). A la recepción de la longitud del telegrama responde, el contador de tiempo de espera ha de ser corregida
especialmente cuando largo mensajes de respuesta de acuerdo con la fórmula anterior.
5,4 asignación lógica
Para los comandos un ID de proceso de 32 bits se puede definir, que es única en el sistema y se utiliza para el
funcionamiento de los diarios, etc .. El ID de proceso es una parte de los datos de un objeto. Se describe en el
documento base OCIT O. La especialización de las unidades de control de señal de luz se puede encontrar en el
O Esfuerzo documento OCIT.
Las respuestas a los comandos pueden llegar en un orden diferente en el tiempo. La asignación lógica se realiza
mediante la dirección IP, el puerto y el número de trabajo de 32 bits (el número de trabajo es parte del Protocolo
BTPPL).
5.5 codificación de los datos
Para la codificación de los datos en OCIT estaciones remotas un XDRFormat modificado se usa (RFC
1014). Para ahorrar ancho de banda siguientes cambios en el formato XDR se llevan a cabo:
• El tamaño del bloque básico (RFC 1014, punto 2) se reduce a 1 byte. El uso de 32 bits por byte es
demasiado grande. , 3.9 y 3.10, el valor de r (sin relleno) se establece en 0 3,8 - De acuerdo con
ello, en los puntos de RFC 1014a
• Además de la entero con signo (RFC 1014, sección 3.1) (16 bits) y un char firmado (8 bits) se
añadió a una-Short Firmado. En consecuencia, la

número entero sin signo (RFC 1014, sección 3.2) (16 bits) y un unsigned char (8 bits) añaden a
un corto sin signo. El relleno tiene lugar, en todo caso.
• se almacenan como valores booleanos unsigned char.
• Las cadenas son siempre con una longitud de palabra de 16 bits (USHORT) muestra que el número de
bytes (!) Indica en la cadena.
• Abhängig von der maximalen Zahl an Elementen wird entweder ein Längenbyte (max. 255
Elemente), ein Längenwort (65535 Elemente) oder ein ULONG vorangestellt, welches die Zahl von
Elementen angibt.
Die Union-Diskriminatoren (die nur sehr selten sind) bleiben bei jeweils 4 Byte Länge, um nicht
verschiedene Typen von Unions einführen zu müssen.
5.6 Objekte
Die Funktions-Aufrufe in OCIT-Outstations sind objektorientiert aufgebaut. Anders als

z.B. bei RPC wird eine Funktion nicht nur durch eine Zahl repräsentiert, sondern durch die Kombination
von Objekttyp, ObjektId und Methode. Dies soll zunächst genauer erläutert werden:
Element Beschreibung
Objekttyp Todos los elementos que se puede acceder en un dispositivo de OCIT se asocian con un
tipo de objeto. Ejemplos de tales tipos de objetos son: plan de señal, detector, registro
(Member,
operativo, etc. Hay un número de tipos de objetos que son muy simples y sólo puede leer
OType)
o escribir acceder el ejemplo, tal como nombre del dispositivo.
El tipo de objeto es descrito por los campos y OTYPE miembros.

miembro es el fabricante que utiliza el objeto escriba el número de socio. En OCIT
estaciones remotas tipos de objetos siempre se introduce un 0 o un 1, para los objetos
específicos del fabricante es aquí el número de fabricación.
OTYPE está el propio tipo de objeto. El número debe ser asignada de forma única para
los objetos estándar. En los objetos específicos del fabricante pueden ser definidos por el
fabricante, ya que los objetos sean distinguibles por los miembros.
Object ID
La mayoría de los tipos de objeto son redundantes. Esto se aplica por ejemplo a la señal
(ZNR, FNº,
Path) planes de 1 a n, detectores de 1 a n, archivos de mensajes de funcionamiento, etc. Para
distinguir la llamada. Instancias de estos objetos, se requiere ID de objeto, que es central
único a través de un operador. A diferencia de la mayoría de los sistemas de comunicación
en
OCIT estaciones remotas esta dirección (objeto ID) de longitud variable y,

elemento descripción
todos "hablar". Esto significa que es posible a partir de la ID del objeto ya se dio lectura a los
datos pertinentes. El ID del objeto para un programa de señal, por ejemplo, consta de tres
elementos: número central (ZNR), número de dispositivo de campo (FNo) y el número de
programa de la señal almacenada en el Camino. Los tres elementos son para el usuario y lo
más importante para los programas de inmediato evaluados y "comprensible".
las entradas ZNR y FNº están presentes en cada ID de objeto, aunque

por ejemplo, un centro de control no tendría ningún número de serie. La razón es que a
partir de la combinación ZNR y FNº puede determinar la dirección de destino del dispositivo.
haría FNº no ser incluido para cada objeto, el panel primero tendría que determinar siempre
desde el tipo de objeto si el objeto tiene que ser transmitida al dispositivo de unión.
la camino no contiene ninguna o sólo un elemento en la mayoría de los casos. Sin embargo, es posible
que el camino también incluye una pluralidad de elementos, siempre y cuando la longitud total no exceda
de 240 bytes.
propiedad
La combinación de tipo de objeto y el ID de objeto se conoce como un objeto. Como se
desprende de las descripciones anteriores, hay por unidad de al menos un objeto (el
dispositivo real) y por lo general también otros objetos. Estas son algunas de las
estaciones remotas OCIT dictada, en parte definida por el fabricante.
método Todas las "funciones" que se ejecutan en un dispositivo OCIT, se refieren a objetos. Por lo
( método) tanto, ellos son tan comunes en la programación orientada a objetos como métodos se
hace referencia. Siempre es posible que los mismos métodos se pueden aplicar a
diferentes objetos. Métodos se agrupan en OCIT estaciones remotas siempre interfaces.
Todos los métodos son funciones con parámetros de entrada y salida y un resultado de la
función. El resultado de la función es un valor de 16 bits. Las primeras 10.000 entradas se
reservan para estaciones remotas OCIT. 0 significa que cuanto más "ejecución perfecta",
mientras que los valores de
1 ... 9999 son de error específico para estaciones remotas OCIT. Los valores superiores a 10000
están reservados para los fabricantes y tienen diferentes significados por el fabricante y por
propiedad.
Los parámetros de entrada y de salida se codifican en un XDRVariante comprimido

(véase la sección. 5,5). Los parámetros de entrada y salida para cada método son fijos y
no cambian, no importa qué objeto se aplica el método. Una excepción son los métodos
de la interfaz 0 (pt. 6.3). Dependen del objeto en particular.
Parámetros en el protocolo OCIT estaciones remotas es cualquier método con 0 ... n Eingangspa-
rametern parámetros de salida llamada y devuelve 0 ... n. cada

elemento descripción
el parámetro puede ser estructurado. Los parámetros de entrada y de salida se codifican

en un formato XDR comprimido.
Cuando los mensajes (métodos sin parámetro de retorno de llamada) los beneficios del
programa sin esperar a la ejecución de la orden (llamada asincrónica).
5.6.1 número de miembros
Con la ayuda del número de miembro sistema de OCIT estaciones remotas para distinguir entre los objetos
y los objetos OCIT fabricante es posible. Miembro 0 y 1 son fijados por los objetos de la ODG OCIT
estaciones remotas. Cuentan con la norma. Los llamados objetos productores son creados de acuerdo con
las reglas OCIT propia responsabilidad de los derechos de autor. La gestión de los números de miembros
es responsabilidad del ODG. Usted lista actual está en el sitio web
www.ocit.org publicada.
5.6.2 Identificación de los objetos
Todos los objetos son identificados por un camino de acceso único a nivel mundial. Esta ruta de acceso se
compone de tres componentes sólidos y un "camino" longitud variable.
• La primera parte fija es el identificador de operador. Esto permite una comunicación transversal
central. Como portador de la identificación de una dirección de dominio real de Internet se puede
utilizar o una dirección de diseño similar una red aislada. Los operadores de dominio no es parte de
telegramas BTPPL, que sólo serán utilizados para construir las conexiones cruzadas clave.
• Para la identificación de dispositivo de 2 entradas en cabecera BTPPL utilizados: El número central

(ZNR) y el número de dispositivo de campo (FNo). El número central es un número único del
centro con un operador. Incluye un rango de 0 ... 65534a El número de dispositivos de campo es
único con respecto al centro. Incluye una gama de valores de 1 ... 65534a El número de
dispositivos de campo para central es siempre el 0 ª Número
Con estas primeras partes del nombre de host y la dirección IP puede ser determinado claramente que
tiene el dispositivo. Un dispositivo siempre se dirige sólo a través de una dirección IP.
La ruta se utiliza para identificar los objetos dentro del dispositivo. Por lo general, consiste en 0 o 1, más
raramente de dos o más entradas. Para los objetos que están presentes sólo una vez por dispositivo, el camino
está vacía. Los objetos tales como detectores, que pueden ser identificadas por una entrada tienen el número
como entrada Path. Sólo los objetos que están por debajo dichos objetos duplicados, tales como entradas de una
matriz, que se produce varias veces en la máquina, tienen más de una entrada (por ejemplo 3).

La estructura de la ruta es identificada de forma única por los miembros y OTYPE. El campo Método en
BTPPL telegrama indica la función de interfaz invoca (método).
La falta de disponibilidad de una llamada desde el centro de control de esta función debe conducir a una reacción
perceptible del dispositivo de campo. Para el comando llamando desde el dispositivo de campo con un código de
retorno negativo es reconocido, mensajes explícitos OCITO el dispositivo de campo no se espera. Sobre la base
de los códigos de retorno negativos del panel de control puede generar mensajes o acciones (característica
opcional y específicos del fabricante implementa el panel de control) apropiados.
Nota: Las reacciones de la sede a los códigos de retorno no son fijos!
5.6.2.1 Selección de los códigos de retorno (RetCodes)
1. Se puede utilizar a pie en las RetCodes métodos, pero sólo se aplica si las condiciones acc.
Descripción.
2. Reunión de las condiciones no lo hacen, otros RetCodes apropiadas seleccionarse de acuerdo con la definición
contenida en el objeto XML RetCode 0:66 (OCIT O_Basis_vv.xml).
3. Si esto aplicar más RetCodes o parece ser adecuado, la selección se lleva a cabo de acuerdo con las
condiciones especificadas en la tabla de abajo prioridades. La prioridad de un valor RetCode tiene que
resolver la ambigüedad en la interfaz propósito OCIT S. Cumple con las condiciones para más valores
RETCODE, la RetCode debe ser enviado a la numéricamente mayor prioridad. La no un código de
colores en los RetCodes mesa ser generado por la aplicación y se envía sobre el alambre.
El verde marcada en las RetCodes tabla generada por el BTPPL-Lib y se envía sobre el alambre.
En caja en las RetCodes tabla generada por la instancia local BTPPL y no enviado sobre el alambre. Por
lo tanto, estos RetCodes tienen una prioridad más alta que los RetCodes la aplicación. los RetCodes
pueden producirse localmente con diferentes prioridades entre la aplicación y BTPPL-Lib.

Prio nombre descripción valor
0 OK Método ejecutado con éxito 0
2 NO_SF Lista no incluye un segundo marco que satisface la condición 1000
3 SF_NOFOLLOW entregado segunda trama es correcta y no más tarde registrada segundo 1002
bastidores presente en la lista.
4 SF_FOLLOW Segundo bastidores entregan correctamente, y el segundo bastidores más 1001

tarde, cuando se introdujeron en la lista
5 ERROR error general 1
10 PARAM_INVALID parámetro incorrecto 32
11 NOT_INACTIVE La lista no puede estar en ejecución para llevar a cabo este método. 1003
12 BUFFER_TOO_SMALL BUFFER_TOO_SMALL: se proporciona cuando el segundo marco puede ser 1005

tan grande que menos de cuatro entradas encajan en el búfer de anillo.
13 CYCLE_TOO_SHORT CYCLE_TOO_SHORT: El tiempo de ciclo especificado es demasiado corto. 1007
14 UNKNOWN_OP UNKNOWN_OP: operador no compatible 1008
15 NO_EVENT NO_EVENT: el evento no se puede entrar por cualquier razón 1009
16 NOT_POSSIBLE si el tipo de orden permite que cualquier elemento de aplicación como sea 1006
posible con los mensajes, R09 y ICLD o cualquier otro trabajo o elementos de
trabajo más.
20 ILLEGAL_STATE La transacción se encuentra en estado ilegal. 38
25 NOT_CONFIGURED La función de referencia no está disponible debido a la falta de suministro 34
29 EXISTS_ALREADY Objeto ya existe, no se llevó a cabo la función. 36
30 INTERVALL_INVALID válido o ya se especifica el intervalo expirado 33
45 ACCESS_DENIED No se permite el acceso a la función deseada. 35
46 ERR_METHOD BTPPL: número método especificado no es conocida / implementado. 8
47 ERR_PATH_VAL encontrado ningún caso a la ruta dada (valor) 17
48 ERR_PATH_LEN longitud de la trayectoria Unexpected 16
49 err_type BTPPL: tipo, que consiste en ODG-MemberID y OTYPE no se conoce / 7

implementado.
50 ERR_DEST_UNKNOWN BTPPL: destino desconocido 9
90 TOO_MANY La función no podría ser ejecutado debido a las restricciones de recursos. 37

Prio nombre descripción valor
100 ERR_BAD_CALLCHK BTPPL: El método fue llamado con una suma de comprobación incorrecta. 2
101 ERR_BAD_CALLTIME BTPPL: La hora de la llamada no es derecho a 30 minutos coincide 3

exactamente con la hora local.
102 ERR_BAD_RETCHK BTPPL: generada por la transmisión desde el transmisor, si la suma de 4

comprobación en el mensaje de respuesta no coincide.
103 ERR_BAD_RETTIME BTPPL: generada después de la transmisión desde el transmisor cuando el 5

tiempo del bloque de retorno está mal, pero el bloque de transmisión era el
momento correcto. En este caso, el comando se ha hecho ya, pero hay una
sincronización del tiempo requerido. Si el código vuelve a aparecer después de la
sincronización de tiempo, esto indica que los hackers o de insectos.
105 ERR_FRAME BTPPL: encabezado no válido (longitud, banderas, suma de comprobación Fletcher) 13
200 ERR_SYNCHRONIZE BTPPL: generada después de la transmisión desde el transmisor cuando el tiempo del 6
bloque de retorno que está mal y el comando ya tenía un tiempo incorrecto desde el
cuarto bloque de transmisión. Este código no se utiliza entre la unidad de control y el
centro de control.
200 OSErr Error general del sistema 18
201 ERR_DEST_UNREACHABLE BTPPL: Target hecho conocido pero en la actualidad inalcanzable 10
202 ERR_TIMEOUT BTPPL: la función se interrumpe con tiempo de espera 11
203 ERR_NOREQUEST BTPPL: ninguna petición encontró para enviar el Respond 12
204 OSERR_SOCKET de error del sistema al crear socket 19
205 OSERR_BIND Los errores del sistema en lazo 20
206 OSERR_CONNECT conectar error del sistema 21
207 OSERR_WRITE error del sistema con escritura 22
208 OSERR_READ error del sistema en modo de lectura 23
209 OSERR_LOCK error del sistema con grave mutex / liberación 24
5.6.3 DNS invalidación de caché
Es posible que durante el funcionamiento, se cambia la dirección IP del dispositivo de campo (pero no su
nombre de host!). BTPPL no debe hacer una consulta DNS para cada comando, porque esta consulta es
en recursos y tiempo. En cambio, los resultados de la consulta deben almacenarse en caché. Para
garantizar la coherencia de la memoria caché tiene que ser una invalidación de caché DNS en BTPPL.
Una vez que esto ocurre, las direcciones correspondientes deben ser redefinidas:

• Cuando se recibe una transmisión con una falsa SHA-1 contraseña
• Después de un tiempo de espera de múltiples
• en el arranque
5,7 asegurar la transmisión en el protocolo OCIT estaciones remotas
• OCIT estaciones remotas telegramas están protegidos por diversas medidas contra la corrupción de
datos o ataques externos.
• OCIT O contraseñas, que suministra aire a cada interlocutor.
• La transferencia de la protección contra la corrupción de los datos y, por ejemplo paquetes UDP mal dirigidas o
ataques desde el exterior se efectúa mediante un algoritmo de Fletcher.
• Se requiere un aumento de la seguridad contra ataques desde el exterior para la transmisión de datos
relacionados con la seguridad y asegurado por un algoritmo SHA-1 (que calcula la suma de
comprobación de las palabras de paso y el contenido de datos).
• La protección de transferencia contra la corrupción de datos se produce en el plano de

transporte (y el uso de PPP en la capa de enlace de datos) cada uno por el protocolo.
5.7.1 contraseñas OCIT O
Para la transmisión de fijación contraseñas son utilizados por los receptores respectivos para la
identificación o la verificación del remitente y el fusible transmisión SHA1 (véase la sección 5.7.3.) Puede
ser utilizado. La aplicación de este método tiene la ventaja de que el acceso al sistema y otros
compuestos no necesariamente tienen que ser asegurado a través de cortafuegos.
Los dispositivos de campo a saber por lo menos las siguientes contraseñas OCIT O:
• Contraseña del dispositivo de campo en sí (cuando se entrega preestablecido a

"OCITPASSWORT")
• sede contraseña (a preset entrega a "OCITPASSWORT")
• centro de la sustitución de contraseñas
• Contraseña del sistema central de acceso

• Contraseña para direcciones IP desconocidas (por defecto)
Para cada uno de estos compuestos un par de contraseñas necesarias:
• La contraseña del propio dispositivo (contraseña del dispositivo de campo, el centro de control o de otras
instalaciones)
o para la identificación del remitente y
o para SHA-1 copia de seguridad de las comunicaciones salientes.

• La contraseña del interlocutor
o para la prueba de admisibilidad de la comunicación entrante y
o para identificar al remitente de telegramas de solicitud.
Como se utiliza una contraseña, la contraseña del remitente en los mensajes de petición y telegramas
de telegramas Responder al remitente del mensaje de solicitud de contraseña correspondiente.
Dado que, por definición, un dispositivo central puede cambiar las contraseñas en los dispositivos de campo, es
necesario reproche allí para cada dispositivo de campo, los correspondientes pares de contraseña. Leer más en el
sistema de documento base OCIT O objeto de dispositivo remoto
Nota: Preferiblemente, todos los dispositivos de campo utilizarán la misma contraseña en el dispositivo de campo dentro de
un sistema centralizado.
5.7.1.1 La instalación de un nuevo dispositivo
• El dispositivo se suministra con la contraseña OCIT O estándar "OCITPASSWORT".
• En el centro una OCIT O contraseña P1 se almacena. (Para cambiar las contraseñas una segunda
P2 entrada se crea en el centro, que está cubierto en el caso normal con el OCIT O contraseña P1).
La OCIT O contraseña P1 también está preajustado a la entrega de la unidad con
"OCITPASSWORT".
• El centro se realiza como el primer comando de cambio de la contraseña OCIT O estándar en el dispositivo de
la contraseña, que se utiliza en el centro de control (Procedimiento ver más abajo).
5.7.1.2 cambio de OCIT O la contraseña de un dispositivo de campo
La contraseña OCIT O se cambia sólo desde el centro de control. El cambio se llevará a cabo de la siguiente
manera:
• El centro envía un comando de cambio de contraseña en el dispositivo.
• La unidad se apaga la contraseña e inmediatamente utiliza la nueva contraseña OCIT O. La respuesta se

transmite no asegurada. Todas las siguientes respuestas y todos los comandos del dispositivo al centro
de control se codifica con la nueva contraseña OCIT S.
• La sede aceptado después de llamar solamente responde sólo con la nueva contraseña OCIT S.
Todos los mensajes restantes en la memoria caché de reintento son recodificados contraseña con la nueva OCIT O.

5.7.2 Seguridad de transmisión por el algoritmo Fletcher
seguridad en la transmisión de datos contra la corrupción se logra en todos los telegramas OCIT estaciones remotas
por el algoritmo Fletcher (suma de comprobación). Además, por ejemplo, paquetes UDP mal dirigidas pueden por lo
tanto ser eliminados. El algoritmo Fletcher es parte del Protocolo de OCIT estaciones remotas. Todos los paquetes
con incorrecta suma de comprobación Fletcher se descartan.
El algoritmo Fletcher es un algoritmo simple pero eficaz que requiere sólo 2 bytes por paquete. Él es un
algoritmo bastante desconocido, lo que hace que los ataques ad hoc:
c0 unsigned char, c1;
initialize_fletcher void () {
c0 = c1 = 0; }
do_check vacío (sin firmar InByte char) {
c0 = (c0 + InByte)% 255; c1 = (+ c0 c1)} 255%
corto Fletcher () {
unsigned hi_fletcher Char = 255 - ((c0 + c1)% 255); unsigned char lo_fletcher = c1;
retorno ((corto) hi_fletcher << 8) | lo_fletcher; }
check_fletcher char () {
retorno (c0 == 0) && (c1 == 0); }
Para ejecutar el algoritmo debe ser llamado initialize_fletcher antes de la formación del byte de suma de
comprobación por cada atributo de datos a continuación do_check y finalmente forman con la suma de comprobación
Fletcher. Para verificar la suma de comprobación se realiza do_check Fletcher suma de comprobación de los datos
de atributos de bloque y (!) Y luego probó con check_fletcher si la suma de comprobación es correcta.

En ensamblador, el algoritmo es más eficiente debido a que el ejemplo de operación do_check se puede disolver en 8086
ensamblador como esto:
MOV al, c0 ; cargado en el c0 Accu

ADD al, InByte; bandera de acarreo se establece si el resultado> = 256 ADC al, 01
; El resultado es correcto, si el total es de 255 o 510,
de lo contrario uno demasiado grande
; Si el resultado es correcto, incluso la bandera de acarreo está ajustado al ADC, FF

; -1 si la bandera de acarreo no está ajustado, de lo contrario + -0
c0 MOV, al ; tienda de C0
ADD al, c1 ; c1 añadir añadir
ADC al, 01 ; tan
ADC al, FF ; tan
c1 MOV, al ; tienda c1
El algoritmo, por supuesto, se puede optimizar más. El ejemplo utiliza sólo las operaciones de 8 bits, y es
por tanto adecuado para portar en un controlador embebido.
Con lo anterior algoritmo Fletcher ser todos los telegramas OCIT estaciones remotas 'salvado'. Esto
asegura que muy pocos telegramas UDP perdidos al azar que se originan de software no OCIT, se
aceptarán como válidos los mensajes y confunden la acción. Además intentos de ataque por personal no
autorizado sean poco probable.
5.7.3 Seguridad de transmisión por el algoritmo SHA-1
comunicaciones relacionadas con la seguridad, tales como nuevos suministros básicos o mensajes
operativos se asegura, además, mediante un algoritmo SHA-1 a los toques intencionales. SHA-1 es una
suma de comprobación que detecta cualquier transferencia y los descartes no autorizado. SHA-1 también
se utiliza en otros contextos para formar firmas digitales y es reconocido como un mundo seguro. El
algoritmo SHA-1 no se utiliza para el cifrado, pero sólo para el cálculo de la suma de comprobación
(algoritmos de cifrado requiere en muchos países un permiso de exportación por separado). La
probabilidad de un paquete falso es reconocido como correcto, es de menos de 10- 48a
El algoritmo SHA-1 se basa en el conocimiento actual libre de derechos de patente.
(Documentación http://csrc.nist.gov/cryptval/shs.html )
otros:
• Según los conocimientos actuales, la posibilidad de diseñar a través del conocimiento de los paquetes
transmitidos previamente un paquete en comparación con la oportunidad de adivinar la contraseña
OCIT O insignificante.
• Se supone que no hay transferencia de datos fisgón seguida durante la fase de instalación del
dispositivo.
• Durante la transferencia normal de datos, intercambio de datos se puede leer.

• Es para evitar que los paquetes de datos válidos se recogen para día y luego transferidos al
dispositivo.
• paquetes de datos garantizados retraso ya sea de forma automática válido.
• La transmisión de datos real es en texto plano para facilitar la depuración, y de manera que no
choquen con las prohibiciones de criptología de ciertos países.
• La protección es una contraseña O OCIT que puede ser cambiado por el panel de control. Un
intruso que no es el viejo OCIT O conozca la contraseña no puede aprender la nueva contraseña
OCIT S.
5.7.3.1 Determinación de la suma de comprobación
Antes de que se forma la suma de comprobación, el campo UTC del bloque de datos BTPPL se llena con la hora actual
del sistema.
Para formar la suma de control del algoritmo SHA-1 se ejecuta utilizando la siguiente secuencia:
• OCIT O contraseña del remitente (sin byte de longitud, la codificación ISO8859-1) lleno con el
binario 0 a 512 bits. (El algoritmo comprime en incrementos de 512 bits, con lo que este primer
bloque de pre-calcula y almacena).
• BTPPL bloque de datos a partir de HdrLen (inclusive) a UTC (LSB) (ambos inclusive).
• la contraseña del OCIT O remitente (sin longitud de bytes, la codificación ISO8859-1). La suma de
comprobación así determinada se escribe en el campo de datos SHA-1 de la BTPPL bloque de datos.
Posteriormente, el algoritmo Fletcher partir de campo HdrLen sobre toda el bloque de datos BTPPL (offset 4
en TCP, UDP compensado 0) se realiza.
5.7.3.2 transmitir una orden
Los comandos se pueden transmitir en tres diferentes niveles de seguridad:
1.) SHA-1 (a solicitud y Responder alta seguridad)

2.) SHA-1 en la solicitud, pero no significa en Respond (seguridad)
3.) No SHA-1
Con SHA-1 comandos seguras:
• Para cada comando que se almacena en el archivo Tipo OCIT estaciones remotas como relevante para la
seguridad, la suma de comprobación se genera con la OCIT O contraseña P1 y añade al final del conjunto de
parámetros.

• El receptor también forma la suma de comprobación para cada comando de seguridad y compara su suma
de comprobación calculada con la suma de comprobación transmitida.
• Si ambos valores son diferentes, el comando es rechazado con un error y dejó un mensaje al
centro de control.
• El receptor compara si el tiempo que se transmite en difiere de mando en más de ± 30 minutos del
reloj interno. Si el tiempo es diferente, el comando es rechazada con un error y también emitió un
mensaje al centro de control.
• La respuesta del comando también se proporciona con la suma de comprobación y se envía de

vuelta al transmisor. Como contraseña se utiliza la misma contraseña OCIT O, que se utilizó en la
solicitud.
• The Central compara la suma de comprobación con la contraseña O OCIT para el dispositivo. esta
comparación falla, las votaciones se interpreta como falso.
• En respuesta a la hora incorrecta la hora local está incluido. Este caso no debería ocurrir
normalmente debido a que los dispositivos deben tener siempre la hora correcta. Para enviar en
tal caso, sigue contando, el cliente debe llamar a un GetTime sin garantía del objeto del sistema y
adaptar el comando en el momento equivocado.

5.7.3.3 Códigos de retorno utilizados por el protocolo de seguridad
Los siguientes códigos de retorno básicos son generados por el protocolo de seguridad / utilizado:
memorándum Descripción número
ERR_BAD_CALLCHK La función se llama con una suma de comprobación

incorrecta. Indica hackers error o contraseña incorrecta O
OCIT.
ERR_BAD_CALLTIM correo El momento de la solicitud no coincide a 30 minutos

exactamente coincida con la hora local.
ERR_BAD_RETCHK Se genera después de la emisión del emisor, si la suma de

comprobación en el mensaje de respuesta no coincide.
Indica hackers error o contraseña incorrecta O OCIT.
ERR_BAD_RETTIME Es generada por la transmisión desde el transmisor cuando

el tiempo del bloque de retorno está mal, pero el bloque de
transmisión era el momento correcto. En este caso, el
comando se ha hecho ya, pero hay una sincronización del
tiempo requerido. Si el código vuelve a aparecer después de
la sincronización de tiempo, esto indica que los hackers o de
insectos.
ERR_SYNCHRONIZE Es generada por la transmisión desde el transmisor cuando el

tiempo del bloque de retorno que está mal y el comando ya tenía
un tiempo incorrecto desde el cuarto bloque de transmisión. Este
código no se utiliza entre la unidad de control y el centro de
control. Si el código vuelve a aparecer después de la
sincronización de tiempo, esto indica que los hackers o de
insectos.
5.8 Examen de la canal TCP
Para comprobar si el canal está todavía abierta, el cliente o el servidor puede enviar un mensaje de prueba a
través del canal TCP. El mensaje de prueba son simples ceros de 4 bytes en una fila. Desde BTPPL espera
que en este punto la longitud de un paquete siguiente (en este caso 0), el mensaje de prueba se puede
instalar fácilmente.

6 tipificación
6.1 objetos de interfaz
Una idea de la OCIT estaciones remotas para definir la interfaz en una forma formal, legible por
máquina. Sirve la siguiente meta:
Figura 4: Metamodel
6.1.1 Tipos de datos básicos:
En SimpleDomain.Basetypename (Entrada BASETYPE NAME) siguientes tipos de datos básicos se pueden

especificar:
tipo de datos Tipo de datos en C máximo válido transmisión observación
básico área
BYTE signed char - 128 ... 127 transmitida como 1-byte (sin 8 bits con signo
alineación)
UBYTE unsigned char 0 ... 255 transmitida como 1-byte (sin 8 bits sin signo
alineación)
BREVE firmó corta - 32.768 ... 32.767 transferidos como 2 bytes, 16 bits con signo
Primer byte alto (sin alineación)
USHORT corto sin signo 0 ... 65.535 2 bytes transmitidos, byte alto 16 bits sin signo
primero (sin alineación)

tipo de datos Tipo de datos en C máximo válido transmisión observación
básico área
LARGO firmado a largo - 2147483648 ... de 4 bytes transmitidos, byte alto De 32 bits con signo
2.147.483647 primero (sin alineación)
ULONG largo sin signo 0 ... 4294967295 transferidos como 4 bytes, 32 bits sin signo
Primer byte alto (sin alineación)
FLOAT flotador - 1E38 1E38 ... Codificación como codificación de número de coma flotante de 32 bits
un solo flotador en 4 bytes en CDR,

pero sin alineación
dOBLE doble - 1E308 1E308 ... codificación como la codificación número de coma flotante de 64 bits
un solo flotador en 8 bytes en

CDR, pero sin alineación
struct {STRING longitud de palabra de la siguiente campo (2 bytes) 1, cadena ANSI terminada en nulo (ISO
USHORT len, char 8859-1 [Latin-1]) caracteres de control son ignorados
str []}
BLOB struct {ULONG SZ, objeto grande binario, se transmiten en el opaco datos.
los datos byte []}
Tabla 1: Tipos de datos básicos
Herencia en el (DOMINIO entrada base en StructDomain) metamodelo para:
• DynAttribut
Los atributos dinámicos son heredados, que es una clase especializada también tiene todos los
atributos dinámicos de su clase base (s).
• STDMETHODS
Los métodos estándar no se heredan. Motivo: La firma del GET, la actualización depende de los
atributos dinámicos del dominio.
• métodos
son heredados, los números de método, sin embargo, son absolutamente indican que debe
tenerse en cuenta que debe ser mayor que MAXMETHODNR la clase base y menos de
MAXMETHODNR su clase es menor que el mayor número método estándar (15 =).
• camino
es con heredado. Si la clase base define un camino, la clase especializada tiene al menos el mismo
camino. Si el dominio de base ya está OBJTYPE, el dominio especializado debe ser un dominio
OBJTYPE. En la OCIT estaciones remotas tipo de ruta de archivo no es nueva dado.
1 La cadena "abc" es la longitud de 4!

6.1.2 elemento meta DECL
El elemento de referencia se refiere a otro tipo (dominio) y pueden toda referencia tipos permisibles
dominio (NÚMERO DOMAIN STRING DOMAIN STRUCTDOMAIN, OBJTYPE etc.).
Los elementos extensibles y REFPATH o REFPATH_DATA especifican lo que se envía a la ubicación

de éstos DECL del tipo referenciado.
REFPATH y REFPATH_DATA se permiten alternativamente y sólo con referencias a tipos de objeto

(dominios OBJTYPE). Si todavía no se especifica ninguna REFPATH REFPATH_DATA, los datos del tipo
de referencia se transferirán a solas. Con dominio simple es la fecha del tipo en sí, en cualquier
StructDomain atributos dinámicos existentes.
6.1.3 REFPATH
Si REFPATH se establece, en una referencia en la forma de un camino es (de ahí el nombre) transmitida
al objeto, que se especifica en el DECL. Por ejemplo, si se necesita una referencia a un nodo relativa en el
DECL se especifica y establecer REFPATH el objeto "nodo relativa". Dependiendo de la dirección
indicada por valor REFPATH (ver abajo) está así transferido, una cierta parte de la trayectoria del objeto
referenciado. REFPATH sólo se podrá establecer si los puntos de referencia a un dominio OBJTYPE (sólo
OBJTYPE dominios tienen una PATH).
Un REFPATH blanco / REFPATH_DATA ningún valor no es válido.
El camino es único en el mundo. Se inicia con
• -Domain operador (String)
• ZNR (2 bytes)
• FNº (2 bytes)
y luego es diferente dependiendo del tipo de objeto. En el caso del nodo relativa todavía sigue de cerca un byte
con el número de nodo relativa. El número de nodo relativa y el número de grupo de la señal: para grupos de
señales dos valores siguen. El camino es de este modo jerárquico.
Desde la primera parte de la ruta en la mayoría de los casos es redundante, se puede especificar cuando
REFPATH cuántos elementos se puede tomar del objeto contenedor y por lo tanto no se transmiten de
forma explícita. Por lo tanto, cuando se dirige un comando a un programa de la señal de un dispositivo de
cruce (el comando está incrustado en el telegrama BTPPL) una lista de AP-valores (que están incrustados
en el comando de programa de la señal), la referencia se divide como sigue:
• La cabecera contiene BTPPL dominio de operador (implícitamente), y FNº ZNR

• El camino de la cabecera BTPPL abordar el comando de programa señal a través de número de nodo relativa y
el número de programa de la señal
• Cada valor único punto de acceso está dirigida únicamente por su nombre.
REFPATH puede tomar valores positivos y negativos. Si REFPATH> = 0, el número de elementos

(acciones ruta jerárquica) está codificado, que se toman desde el objeto contenedor. El resto de los
elementos de trayecto del objeto de destino se transmite en lugar de la referencia.
Las más importantes son:
0: No suposición implícita de acciones de trayectoria, es decir, todos los elementos de la ruta del dominio de
operador objetivo ZNR, FNº y todas las demás acciones de trayectoria se transfieren.
1: dominio de operador se supone implícitamente. ZNR, FNº y el camino más del objeto
referenciado a ser transferidas.
3: Dispositivo-relacionados. Operadores ZNR, FNº ser aceptado implícitamente la ruta más

dentro del dispositivo de campo se transmite
4: Basado en el nodo relativa, si el objeto incrustado se basa realmente en el nodo relativa.

transmitido el camino de juego jerárquicamente de acuerdo con el nodo relativa
5: Objeto basado en el objeto de encerramiento. Hace referencia a un objeto que encierra un

elemento en sí mismo objeto. Desde el objeto de referencia son las acciones ruta jerárquica
adicionales que no son ya parte de ella rodea la propiedad transferida.
Si REFPATH <0, esto significa: Sólo para referencia, los siguientes valores nletzten se transmiten. En -1, por
ejemplo, la referencia se establece sólo a través del último elemento trayectoria del objeto de destino en -2
por los dos últimos elementos de la ruta del objeto de destino, etc.
Si REFPATH no se establece, no de referencia es (por lo tanto sólo los datos como se muestra 6.1.2.)
Transferencia.
6.1.3.1 REFPATH_DATA
REFPATH_DATA transmite la ruta como REFPATH, pero también conduce a la final de la ruta de los
elementos de datos, por lo que los atributos dinámicos posiblemente existentes. La numeración es la
misma que REFPATH.
6.1.3.2 EXTENSIBLE
Nota: Función se ha cambiado en comparación con la versión anterior (datalen = 2 o 4 bytes)!
EXTENSIBLE se especifica cuando diferentes tipos de objetos derivados de la especificada en el tipo

DECL de datos a transmitir. el elemento

EXTENSIBLE puede no contenido (por ejemplo: <EXTENSIBLE />) se puede especificar como un contenido o
con el dígito '4'. En el primer caso, la datalen con 2 bytes como USHORT cuando el contenido de 4, la datalen se
transmite con 4 bytes como ULONG.
Con conjunto ampliable tres elementos se establecen con REFPATH conjunto o

REFPATH_DATA antes de la REFPATH:
• Longitud de los datos transmitidos de la referencia (incl. Miembro / OTYPE) en bytes (rango 4 ...
255)
• Miembro (2 bytes)
• OTYPE (2 bytes)
que sigue el camino de lo dado a través del miembro y el tipo OTYPE.
En REFPATH_DATA todavía sigue:
• longitud datalen de siguientes datos en bytes como 2 o 4 bytes codificados (ver arriba).
• La información dada por los miembros, el tipo OTYPE (con dominio simple es la fecha del tipo en
sí, cuando StructDomain los atributos dinámicos existentes).
EXTENSIBLE se establece sin REFPATH o REFPATH_DATA se transmite en su lugar después de esta

DECL:
• Miembro (2 bytes)
• OTYPE (2 bytes)
• longitud datalen de siguientes datos en bytes como 2 o 4 bytes codificados (ver arriba).
• La información dada por los miembros, el tipo OTYPE (con dominio simple es la fecha del tipo en
sí, cuando StructDomain los atributos dinámicos existentes).
6.1.3.3 MINCOUNT MaxCount
Los campos MINCOUNT y MAXCOUNT indican el número de elementos declaradas en la presente Decl.
Ambos campos son opcionales, si se han perdido MINCOUNT válida = MaxCount = 1, que es
exactamente uno de los especificados en el tipo de referencia. MaxCount siempre debe ser mayor que o
igual MINCOUNT.
Si se MaxCount MINCOUNT más grande, hay una matriz. En este caso, se puede anteponer el número
de elementos reales. Este número es un UBYTE si MaxCount-MINCOUNT <256, de lo contrario un
USHORT.
PATHPART no puede contener matrices, es decir, MINCOUNT = = MaxCount primera

6.1.4 elemento meta MSGPART
El MSGPART elemento meta es sólo un STRUCTDOMAIN especial, están predefinidos en los tres atributos
de clase: la categoría y formato de grados. Categoría incluye la categoría de mensaje como un número, el
MeldungsDegree grado que un número y formato a la cadena de formato.
6.1.4.1 cadenas de formato
Nota: La función se compara con la versión 1.1 se expande (formato de cadena de sumas de comprobación)!
Como parte de OCIT es posible extender el estándar para objetos y métodos específicos del fabricante.
Para exponer estas extensiones a otros fabricantes cuando se utilizan diferentes sistemas de los
fabricantes, estos objetos son para describir completamente como un archivo XML (<proveedor>
AddOns.xml). Aquí, el prescrito en OCIT nomenclatura estándar para ser utilizado. Esto es
particularmente relevante en los mensajes secundarios. Para que puedan ser analizados de forma
automática desde el centro a mostrar y procesar un texto claro y mostrar estos mensajes en la superficie
es posible, la presentación deberán respetarse exactamente. Sólo se presentó un breve texto
característico para el mensaje. Puede contener cualquier texto y valores adicionales del mensaje. Desde
un mensaje, pero por lo general tiene una pluralidad de parámetros de mensaje, que contienen valores
diferentes, el valor debe ser utilizado en formato de tiempo de ejecución en el texto. Para indicar qué valor
de un parámetro del mensaje que se utilizará, el nombre del parámetro entre el signo @ debe estar en el
formato de texto.
El nombre o identificador de los parámetros de los mensajes que se pueden utilizar en una cadena de formato
con @ ... @ debe cumplir con el consiguiente "ruta" con el valor que se mostrará, (en lo sucesivo, ValuePath). En
el caso más simple, la valuePath sólo la simple nombre del parámetro del mensaje. A menudo, sin embargo, se
abordará un valor sobre una pluralidad de referencias de objetos de modo que los resultados en un punto por
separado ValuePath. la valuePath se muestra por ejemplo en el código HTML de la documentación de la
herramienta Texto.
Ejemplo: Un mensaje tiene los parámetros del mensaje con el valuePath
abc con el valor de 4711
a continuación, el texto de la siguiente formato debe mirar en la gramática:
<TAMAÑO> El valor es @abc @ </ FORMATO>
Después de la evaluación del formato de cadena de formato del texto se mostrará de la siguiente manera:
El valor es 4711
característica especial de los valores de la matriz:

Contiene un mensaje de los valores de la matriz, incluso esto se puede visualizar en formato de texto. Si contiene
un mensaje tal como los siguientes parámetros y valores

xy [0] .z = 4712
xy [1] .z = 4713
los valores con el siguiente formato al texto se pueden visualizar:
<Tamaño> valores de matriz @xy []. Z @ </ FORMATO>
Después de la evaluación de la cadena de formato todos los valores de la matriz a continuación, se mostrarán:
valores array [4712 4713]
Para las sumas de comprobación se utiliza siguiente representación:
Las sumas de comprobación generados (20 bytes) son para ser mostrado en aras de la facilidad de lectura en 10
grupos, cada uno de 4 caracteres hexadecimales. Ejemplo: CAFE 1234 ABCD5678-A1B2-C3D4-1A1D-1234 CAFE
ABBA
6.1.5 MÉTODO
Este elemento meta describe un método. Un método tiene un número único dentro de la interfaz o
OBJTYPES (y sus dominios de bases) en la que se encuentra.
Un método tiene parámetros de entrada y de salida que se declaran en el vehículo de entrada IN y OUT.
BTPPL transmite los parámetros de entrada con una petición de que el parámetro de salida con un
telegrama Respond.
El AUTH entrada se afirma que:
• Solicitud y Responder (AUTH = completo)
• solamente la solicitud (AUTH = Request)
• No solicitarán ni responder (AUTH = None)
se va a realizar con SHA-1 de autenticación.
Nota: En las versiones OCIT O 1.0 y 1.1 de la autenticación de manera no puede seleccionarse en todos los
métodos. Si el AUTH día que falta en la definición de los métodos, se le considera como AUTH = Ninguno.
6.1.6 Atributos de clase
Los elementos de atributos de formulario-definida de un StructDomain después de que el principio clave /

valor. Un nombre de clase atributo consta de la día, la clave y el valor de día, el valor, y cualquier
descripción adicional. El significado depende del tipo específico (dominio), es decir, un atributos de clase
de un tipo MSGPART por lo general tiene un significado diferente por ejemplo, una orden (OBJTYPE).
Dentro de un tipo (StructDomain,

MSGPART o OBJTYPE) es una clave única. por lo que son conocidos y válida para todas las instancias de
objetos de un tipo. Los atributos utilizados para almacenar definiciones que no pueden ser descritos por la
forma general de metamodelo XML en la especificación, en forma legible por máquina. El contenido de las
etiquetas de valor depende de la clave (los atributos de clase de tipo, el día NOMBRE). El uso de atributos
se especifica a continuación.
6.1.6.1 MARCO
(Key se define para OBJTYPE, orden): especifica el marco orden que es escrito por este orden en un
segundo marco. Los días valor Devuelve la referencia a miembro / OTYPE uno de 0: 290 a abzuleiteten
Structdomain que describe el formato de trama. El dominio referenciado describe un marco completo
orden. El marco de orden se especifica con <# miembros>: <AuftragsFrame_Typname> (Ejemplo: 0:
MWAuftragFrameR09). Este atributo se puede utilizar para los pedidos para los que el formato de datos es
estático, como telegramas RBL.
6.1.6.2 FRAME_DATA
(Key se define para OBJTYPE, AE): especifica los datos de usuario a ser escritos por este elemento de
aplicación en el marco de orden. La etiqueta de valor especifica la referencia a miembro / OTYPE un
dominio que describe el formato de los datos en el marco nombre. Se hace referencia a un dominio simple,
el valor escalar se escribe en el AF. En una StructDomain sus atributos dinámicos en el AF se escriben.
(Ejemplo: 1: intervalo de tiempo). El atributo se puede utilizar para describir el formato de datos de las
órdenes en el que el formato de trama de orden resultante dinámicamente a partir de la asignación de
elementos de contrato a la orden. El atributo de clase se asocia así elementos de aplicación.
6.1.6.3 CATEGORÍA
(Key se define para MSGPART): Indica un mensaje a una sub-categoría, por ejemplo, hardware, sistema de
transmisión, el programa de usuario.
6.1.6.4 GRADO
(Key se define para MSGPART): especifica la gravedad del mensaje.
6.1.6.5 FORMATO
(Clave se define para MSGPART): especifica un formato de texto para la presentación del mensaje. La
cadena de formato puede contener parámetros de un elemento de MSGPART definido dentro de las
etiquetas decl
6.2 definiciones de datos
Las definiciones de los datos utilizados en OCITOutstations dividen en objetos y objetos OCITOutstations
fabricante. Para se utiliza su descripción exacta de la norma XML, el (los fabricantes líderes de software
Microsoft,

es compatible con Oracle, ...), sino también en la escena software libre (Linux). documentación
adicionales incluyen bajo http://www.w3c.org/xml de encontrar.
6.2.1 OCIT archivo DTD Outstation
el archivo OCIT O DTD_Vx.x.dtd describe la estructura de toda la usada en el dominio de la OCIT estaciones
remotas archivos de tipo. Véase también la sección. 6.2.3.
6.2.2 OCIT estaciones remotas archivos de objetos-TYPE
Los objetos OCIT estaciones remotas son descritos por los ficheros del tipo:
• el archivo TYPE_Vx.x.xml basado en OCIT-O que contiene las definiciones básicas
• el archivo OCIT O TYPE_Vx.x.xml dispositivo de campo contiene las definiciones para ciertos tipos de
dispositivos de campo.
6.2.3 Estructura de los archivos de tipo
Todos los tipos de archivos se estructuran de la siguiente manera. El día principal es OCT ( OC informática T IPO).
<! ELEMENT nombre (#PCDATA)> <! ELEMENTO

DESCRIPCIÓN (#PCDATA)> <! ELEMENT MIN
(#PCDATA)> <! ELEMENT MAX (#PCDATA)> <!
ELEMENTO VALOR (#PCDATA)> <! ELEMENT miembro
( #PCDATA)> <! ELEMENT OTYPE (#PCDATA)> <!
ELEMENT NO_TCP (#PCDATA)> <! ELEMENT BASE
TIPO DE NOMBRE (#PCDATA)>
<! ELEMENTO DE DOMINIO (NOMBRE DESCRIPCIÓN, MIEMBRO, OTYPE)>
<! ELEMENTO DE CLASE atributos (nombre, descripción, valor)> <! Elemento de

referencia (NOMBRE MIEMBRO)> <! ELEMENT base del dominio (NOMBRE
MIEMBRO)> <! ELEMENT MINCOUNT (#PCDATA)> <! ELEMENT MaxCount
(#PCDATA)> <! ELEMENT REFPATH (#PCDATA)> <! ELEMENT REFPATH_DATA
(#PCDATA)> <! ELEMENT extensible (#PCDATA)>
<! ELEMENT DECL (NOMBRE descripción, referencia, (MINCOUNT, MaxCount), (REFPATH |???? REFPATH_DATA), ampliable)>
<! ELEMENT STRUCTDOMAIN (NOMBRE DESCRIPCIÓN, MIEMBRO, OTYPE, Dominio de la Base?, * DECL los atributos de clase *)>
<! ELEMENT GRADO (#PCDATA)> <! ELEMENT

categoría (#PCDATA)> <! ELEMENT FORMATO
(#PCDATA)>
<! ELEMENT parte del mensaje (NOMBRE DESCRIPCIÓN, MIEMBRO, OTYPE, base del dominio?, * DECL los atributos de clase * Categoría, grado,
FORMATO)>
<! ELEMENT NULLVAL (#PCDATA)> <! ELEMENT

RESOLUCIÓN (#PCDATA)> <! ELEMENT UNIDAD
(#PCDATA)>
<! ELEMENTO NÚMERO DE DOMINIO (NOMBRE DESCRIPCIÓN, MIEMBRO, OTYPE, BASETYPE NOMBRE, MIN MAX?,?, NULLVAL?, RESOLUCIÓN?, UNIDAD?)>
<! ELEMENT MAXLEN (#PCDATA)>

<! ELEMENT CADENA DE DOMINIO (NOMBRE DESCRIPCIÓN, MIEMBRO, OTYPE, BASETYPE NOMBRE, MAXLEN)>
<! ELEMENT ENUMENTRY (Nombre, descripción, valor)>

<! ELEMENT BASEENUM (NOMBRE DE MIEMBRO)>
<! ELEMENT ENUMDOMAIN (NOMBRE DESCRIPCIÓN, MIEMBRO, OTYPE, BASETYPE NOMBRE, MAX, BASEENUM?, ENUMENTRY *)>

<! ELEMENTO (DECL +)> <! ELEMENT OUT (DECL
+)> <! ELEMENT AUTH (#PCDATA)> <! ELEMENT NR
(#PCDATA)> <! ELEMENT MAXMETHODNR
(#PCDATA)> <! Método de los elementos
> (? Nombre, descripción, NR, AUTH?, EN?, OUT)

<! Elemento de la interfaz (Nombre, descripción, MIEMBRO, MAXMETHODNR, MÉTODO *)>
<! ELEMENT PATHPART (nombre, descripción, referencia, (REFPATH |?? REFPATH_DATA), ampliable)!>
<! ELEMENT METHODNR_OFFSET (#PCDATA)> <! ELEMENT

STDMETHOD (#PCDATA)>
<! ELEMENT IMPLEMENTS (NOMBRE, MIEMBRO, METHODNR_OFFSET)>
<! ELEMENT OBJTYPE (Nombre, descripción, MIEMBRO, OTYPE, Dominio de la Base?, * DECL los atributos de clase *
PATHPART * * STDMETHOD (MAXMETHODNR, MÉTODO *)?, Implementos *)>
<! ELEMENT FABRICANTE (#PCDATA)> <! TIPO

dispositivo elemento (#PCDATA)> <! ELEMENT
VERSIÓN (#PCDATA)> <! ELEMENT Subversion
(#PCDATA)>
<ELEMENTO DE OCT (fabricante, tipo de dispositivo, la versión, la subversión, NO_TCP, (DOMINIO |? NÚMERO DE DOMINIO | CADENA DE DOMINIO |
ENUMDOMAIN | STRUCTDOMAIN | MSGPART | INTERFACE | OBJTYPE) *)> <! ELEMENT !! OCIT_TYPE_DATEI (OCT +)>
El significado de cada elemento se explica mediante un ejemplo a continuación. El ejemplo no tiene

relación con las estructuras reales OCIT estaciones remotas, que sólo sirve para ilustrar la estructura del
archivo Tipo OCIT estaciones remotas. El comentario es en cada caso después de la línea. Con el fin de
no hacer la descripción demasiado tiempo, son partes irrelevantes para la comprensión, es decir, cortar
todas las cosas que se repiten con [...].
<? Xml version = codificación "1.0" = "ISO-8859-1"?>

Esta línea se indica solamente que se codifica en un archivo XML 1.0 en el conjunto de caracteres ISO8859-1. La línea se fija para todos los suministros
<! DOCTYPE OCIT_TYPE_DATEI SISTEMA "ocit.dtd">

La referencia a la información estructural utilizado. Si no hay ninguna entrada, se aceptan los archivos XML
<OCIT_TYPE_DATEI>
<OCTAVE>
El verdadero comienzo del archivo Tipo OCIT
<FABRICANTE> Semáforo Power Ltd. </ FABRICANTE>
Fabricante del dispositivo de unión. El fabricante en el ejemplo es ficticio, ya que todo el archivo de suministro.
<Tipo de dispositivo> semáforo estándar </ DISPOSITIVO DE TIPO>

Tipo de dispositivo de paso ferroviario
<Versión> 1 </ VERSION>
Versión OCIT asociado
<SUBVERSION> 15 </ SUBVERSION>
Específico del proveedor. numeración
<NÚMERO DE DOMINIO>
tipo de datos numérico que se utiliza después. Los tipos enteros y punto flotante se especifican con NÚMERO DE DOMINIO.
si sólo los valores individuales tienen significado, es en lugar de INTDOMAIN un ENUMDOMAIN (ver abajo)
<Nombre> ZEITSTEMPEL_UTC </ NOMBRE>

Nombre del tipo de datos. Los nombres se estructuran como identificadores en C. Es decir, no deben contener en blanco y puntos en particular.
<Description> Tiempo Universal Coordinado </ description>

Descripción del tipo de datos
<Miembro> 0 </ miembro>
el fabricante dentro de la ODG, que define el número de objetos de Access. Los números de fabricante son asignados por el ODG. Los objetos que
se definen en la norma, el campo miembro tienen la entrada 0
<OTYPE> 48 </ OTYPE>

<BASE TIPO NOMBRE> ULONG </ BASE TIPO NOMBRE>
Tipo de base del dominio. Estos son los tipos básicos de bytes, corto, largo, UBYTE, USHORT, ULONG, float, double, CADENA, wstring, BLOB
permite, ver Tabla 1: tipos de datos básicos.
<MIN> 1 </ MIN>
Más pequeño número permitido de tipo
<MAX> 0xFFFFFFFF </ MAX>

número máximo admisible de la del tipo. Para los programadores no-C: 0xF el número "F" significa en hexadecimal, por lo que el decimoquinto
<NULLVAL> 0 </ NULLVAL>

Valor - Si se establece - tiene el significado de que una variable no está definida con este valor como el contenido.
</ NÚMERO dominio>

<ENUMDOMAIN>
La lista de los valores de significado (por ejemplo, para la enumeración de)
<Nombre> RetCode </ NOMBRE>
<Descripción> valor de retorno general de métodos </ description> <miembro> 0 </ miembro>
<BASE TIPO NOMBRE> USHORT </ BASE TIPO NOMBRE> <MAX> 999
</ MAX>
Valor máximo de la gama ENUM
Es posible que ciertas listas se utilizan repetidamente. Para ello existen
BASEENUMDOMAIN la entrada opcional que sería exactamente en este punto. La entrada contiene una referencia a un tipo anteriormente
declarado, que es también un ENUMDOMAIN. Cuando se establece una BASEENUMDOMAIN, todas las entradas se toman este ENUMS y
cualquier nuevos valores deben ser mayores que el valor MAX de BASEENUMDMAINS. Cuando existe un BASEENUMDOMAIN, incluso se
puede prescindir de MAX y otras entradas de entrada.
<ENUMENTRY>
Una entrada para la zona ENUM
<NOMBRE> Aceptar </ name>
Identificación de entrada
<Descripción> Método ejecutado con éxito </ description> <valor> 0 </ VALUE>
El valor real. Debe ser inferior a MAX.

</ ENUMENTRY>
<ENUMENTRY>
La siguiente entrada para la zona ENUM. Hay 'ningún' muchas entradas posibles.
<Nombre> ERROR </ NOMBRE>
<Description> Problemas comunes </ description> <valor> 1 </ value> </
ENUMENTRY>
[...]
</ ENUMDOMAIN>
[...]
<STRUCTDOMAIN>
Además de los tipos de datos de dominio, hay tipos de datos de estructura que corresponden a los de struct conocidos o registros en PASCAL. Cada
elemento de una estructura es a continuación (véase más adelante) en un DECLFeld almacenado. dimensionales son posibles. matriz multidimensional se
da, ya que estos pueden ser declarado siempre como una matriz de una estructura que es una matriz de nuevo, y ser comprendidos este (un poco más
largo) definición tiene la ventaja cuando se trata de la estructura del telegrama.
<NOMBRE> INTERVALO DE TIEMPO </ name>

<Descripción> un intervalo de tiempo absoluto </ DESCRIPCIÓN> son <miembro> 0 </ miembro>
<OTYPE> 63 </ OTYPE> <DECL>
<NOMBRE> Hora de inicio </ name>

<Description> hora de inicio del intervalo </ description> <referencia>
Una referencia es una entrada especial que sólo puede referirse a las definiciones de dominio. Los anuncios son DOMINIO, NÚMERO DE
DOMINIO ENUMDOMAIN, CADENA DE DOMINIO STRUCTDOMAIN, OBJTYPE. Los siguientes campos indican que una definición de dominio
denominado ZEITSTEMPEL_UTC de Odgmember 0 (= ODG) es referenciada.
<Miembro> 0 </ member> <NOMBRE>

ZEITSTEMPEL_UTC </ name> </ REFERENCIA> </
DECL> <DECL>
<Nombre> Endzeit </ NOMBRE>

<Descripción> tiempo final del intervalo de </ description> <referencia>

ZEITSTEMPEL_UTC </ name> </ REFERENCIA> </ DECL>
</ STRUCTDOMAIN>
<Interface>

Una interfaz es una colección de métodos que son usados por múltiples tipos de objetos. En una se agrupan los métodos de interfaz y sus ajustes de
parámetros .. Hacer referencia de la interfaz se realiza a través de una combinación de miembros y nombre. El usuario es un número de la empresa que
ha diseñado el Inerface. La lista de todos ODGMember se dan en el documento. 1
<NOMBRE> Archivo Leer </ name>

Nombre de la interfaz debe ser único, junto con el miembro.
<Descripción> Esta interfaz se utiliza para archivos en F Z leer </ description>
Explicación del nombre
<Miembro> 0 </ miembro> <MAXMETHODNR> 8 </
MAXMETHODNR>
Devuelve el número más métodos reservados de esta interfaz. Cuando un OBJTYPE implementa una interfaz, todos los métodos de todas
implementadas por estos métodos OBJTYPE deben estar numeradas. Si esta interfaz se extiende y números de método sin embargo están
disponibles, los números de método restantes permanecen de todos modos.
<Método>
Funcionalidad ofrecida por la interfaz. Hay en OCIT no hay procedimientos o funciones, únicos métodos. Un método es como asignado aquí una
interfaz, o directamente a un objeto.
<Nombre> GetAeltestes </ NOMBRE>

nombre del método
<Descripción> más antiguo elemento de archivo y su posición de archivo
leer </ description>
Explicación del nombre
<NO> 1 </ NR>
método NR. Como se aprueba No rango de números de 1..MAXMETHODNR, por métodos que se almacenan directamente en el objeto,
sólo el área de 16..64535.
<AUTH> NO </ AUTH>
La entrada puede AUTH siguientes valores Accept: Ninguno ninguna copia de seguridad de los parámetros utilizando SHA-1
Solicitud de suma de verificación Sólo los parámetros de entrada se guardan con la suma de comprobación SHA-1. completo
Los parámetros de entrada y de salida se almacenan con SHA-1 suma de comprobación. Si no hay ninguna entrada,
los parámetros de entrada y de salida se guardan.
<OUT>
Gama de parámetros de salida. Los parámetros de entrada a la virtualmente mismo tipo definido (<IN>) y deben ser definidos antes de que los
parámetros de salida. Para los parámetros de entrada, la entrada ENUMDOMAIN faltante. Cuando el parámetro OUT no está presente, el método
no se responde con una petición / respuesta, pero con un mensaje. Puede por lo tanto, en métodos sin parámetros de salida no puede
garantizarse que la llamada se produjo a través de. Para ello, la llamada muy rápidamente (por ejemplo, para visualización de datos, etc.)
<DECL>
El primer parámetro OUT es el valor del resultado de la llamada al método. El tipo de datos hace referencia debe ser RetCode o
especialización de este. Este valor incluye se devuelven los errores de las capas de protocolo inferiores.
<Nombre> ret </ NOMBRE>

<Description> Aceptar KEIN_ELEMENT, error </ description> <referencia>
<Miembro> 0 </ member>

<NOMBRE> RetCode </ name> </
REFERENCIA> </ DECL> <DECL>
parámetros de salida adicionales son declarados por declaraciones Asev tales como elementos estructurales en el modelo.
<Nombre> PosNo </ NOMBRE>

<Descripción> número de artículo del elemento entregado </ description> <referencia>

ARCHIVPOSNR </ name> </ REFERENCIA> </
DECL> <DECL>
<Nombre> elemento </ name>

<Description> elemento más antiguo </ description> <referencia>

ARCHIV_ELEMENT </ name> </ REFERENCIA>
<ENCODETYPE> IdData </ ENCODETYPE>

ENCODETYPE muestra la manera en que se transmiten los datos dinámicos de tipo referenciado (ARCHIV_ELEMENT). IdData
indica que el ID y los datos se transmiten. Esto es ventajoso si se transmiten diferentes especializaciones (elementos de archivo
especial). El ID se compone de miembros y OTYPE el tipo de datos transmitidos. Missing este campo también lo es el equivalente de
los datos, es decir, sólo se transmiten los datos.
</ DECL>

</ OUT> </
method>
<method>
[...]
</ MÉTODO>
<METHOD>
<Nombre> GetElementeSeit </ NOMBRE>
<Descripción> elementos de tiempo Handed </ description> <NO> 3 </ NR>
<NOAUTHENTIFICATION />
Si esta entrada se establece, los parámetros de entrada y de retorno del método no se guardan con la suma de comprobación SHA-1. Si no hay
ninguna entrada, se almacenan los parámetros.
<IN>
Gama de parámetros de entrada. Los parámetros de entrada se definen en la virtualmente misma manera que los parámetros de salida
<DECL>
<NOMBRE> Tiempo </ name>
Tiempo para estar en qué elementos Lee <description> </ description> <referencia>

DECL>
[...]
</ EN>
<OUT>
[...]
<DECL>
<Nombre> elementos </ NOMBRE>
<Description> Leer elementos. Puede diferente de
ARCHIV_ELEMENT derivarse tipos. </ Description>
<Referencia>
ARCHIV_ELEMENT </ name> </ REFERENCIA>
<MaxCount> 1024 </ MaxCount> <ENCODETYPE>

IdData </ ENCODETYPE>
Aquí, una matriz se transmite con los tipos de variables, es decir, primero el número real se transmite como una serie de
elementos UWORD y entonces un número correspondiente de elementos provistos cada uno con ID (que consiste en miembros y
OTYPE) y de datos.
</ DECL> </
OUT> </ MÉTODO> </
INTERFACE>
<OBJTYPE>
El tipo de objeto de que se declare OBJTYPE. Se compone de varios elementos: el tipo de la estructura de los datos se determina, que se puede leer con la
ayuda de Get y escrita por actualización. Obtener y actualización del sistema son métodos que no es necesario declarar una y otra vez, ya que están
codificados. Con interfaces nombre de la interfaz que se enumeran son apoyados por el objeto. Las interfaces ya están declarados anteriormente. En
STDMETHOD especifica qué funciones estándar (crear, eliminar, GET, Update) son compatibles. Finalmente, en el método se definen métodos, que se
aplican sólo a este tipo de objeto individual y para ningún otro tipo de objeto. El sistema tiene sólo acaba de patrimonio público. Si hay varios tipos de
objetos deben apoyar los mismos métodos, una interfaz debe ser declarada.
<Nombre> StoerungsFehlerArchiv </ NOMBRE>

<Description> Archivo de avisos de fallo y de error </ description> <miembro> 0 </ member> <OTYPE> 299 </
OTYPE>
Número del tipo de objeto (1..65535).

no DOMAIN entrada base, es decir, StoerungsFehlerArchiv hay especialización de otro dominio.
no hay entradas decl, es decir, no los propios datos (públicas). no hay atributos de clase
hay camino, es decir, por dispositivo de campo puede sólo una instancia con el miembro = 0, OTYPE entrar = 299a No hay STDMETHODS Si no
se define de datos separado, los métodos estándar no son útiles.
<MAXMETHODNR> 30 </ MAXMETHODNR>

posibles métodos numéricos más grande
<implementa>
Este objeto implementa la interfaz hace referencia a continuación. Todos los métodos especificados en la interfaz están disponibles para esta
propiedad, por lo que deben ser implementadas.
<NOMBRE> Archivo Leer </ name>

Nombre de la interfaz cuyos métodos el objeto admite.
<METHODNR_OFFSET> 15 </ METHODNR_OFFSET>
La transmisión en números de métodos BTPPL se calculan a partir del número + 15 se hace referencia en la interfaz, por lo tanto tiene el
número del método décimo octavo GetElementeSeit
</ Implementa> </
OBJTYPE> <OBJTYPE>
<Nombre> ZSignalProgramm </ NOMBRE>

<Descripción> reclutado por la solicitud de central de conmutación de programa de la señal </ description> <miembro> 0 </ miembro>
<OTYPE> 222 </ OTYPE> <DECL>
<NOMBRE> Noticias </ name>

<Descripción> petición de conmutación central actual o más recientemente set </ description> <referencia>

<NOMBRE> ZSO_SIGNALPROGRAMM </ name> </
<NOMBRE> Siguiente </ name>

<Description> La próxima vez que la solicitud de conmutación central </ description> <referencia>

REFERENCIA> </ DECL> <PATHPART>
Los objetos que son varias veces en un dispositivo de campo se hace referencia claramente a través de un camino. Esta ruta se especifica aquí.
<Nombre> RelKnotenNr </ NOMBRE>

<Descripción> parámetro Path es el número de nodo relativa. Por lo tanto, varios
controladores de nodos posibles dentro de un dispositivo de campo. </ description>
<Referencia>
OBJECT_ID_UBYTE </ name> </ REFERENCIA>
</ PATHPART>
<STDMETHOD> Obtener </ STDMETHOD>
Las variables del tipo de objeto se pueden leer, pero sólo todos juntos. Para poder editar las variables por separado, el objeto de otro tipo de objeto
debe ser el objeto .IF tipos se integran directamente, es posible leer todo el objeto, con un enlace a través referencia solamente la referencia
respectiva regresa.
<MAXMETHODNR> 32 </ MAXMETHODNR>

<METHOD>
<Nombre> interruptor </ name>
<Description> aceptar el programa de la señal vecino petición de la central de conmutación
</ Description>
<NO> 16 </ NR>
<IN>
<DECL>
<NOMBRE> Cambio de orden </ name>
<Descripción> entregado de Central de conmutación Orden </ description> <referencia>

REFERENCIA> </ DECL> </ EN> <OUT>
<DECL>
<Nombre> ret </ NOMBRE>
<Description> Aceptar PARAM_INVALID, INTERVALL_INVALID </ description> <referencia>

<nombre> RetCode </ name> </ REFERENCIA>
</ DECL> </ OUT> </ MÉTODO> </ OBJTYPE>
[...]
</ PTU>
</ OCIT_TYPE_DATEI>

6.3 interfaces estándar
En los minutos dos áreas son fijos: la interfaz del sistema y el objeto del sistema. La interfaz del sistema
consta de los métodos de 0 ... 15, que incluye varias funciones para cada objeto.
El objeto del sistema es el objeto de la ODG 0 miembros. El subtipo es siempre 0. Sólo contiene las
funciones de programación y lectura de la contraseña OCIT S. Estas funciones no se combinan en una
sola interfaz, pero se muestran en la interfaz de 0 características especiales.
6.3.1 System Interface
La interfaz del sistema tiene las siguientes funciones:
No. nombre entrada salida
0 obtener , /. estado + ESTE TIPO
1 actualización ESTE TIPO estatus
2 crear ESTE TIPO estatus
3 borrar , /. Lista de estado de referencia +
4..15 (Reservado)
Para utilizar un método estándar es entrar en el elemento OBJTYPE.STDMETHOD el nombre antes

mencionado. Aquí, este tipo es la estructura de datos del objeto en sí incl. Las estructuras de datos de
todos los sub-objetos. Las referencias no se resuelven con su contenido, pero con una estructura
REFPATH. 2
El estado es el estado por defecto de la cirugía (RetCode) (véase más adelante).
Específicamente, las características de trabajo como sigue:
6.3.1.1 Get
Get no recibe los parámetros de entrada y tiene (además del estado funcional) parámetro sólo una salida.
El parámetro de salida varía en función del tipo de objeto y es sólo la estructura que está en la lista
entradas Asev de DynAttribut (y todos los dominios de bases) de OBJTYP especificados.
2 Nota: Esta técnica hace que sea fácil de construir un navegador. Todos los objetos complejos que pueden ser tratados por separado, que se
refiere sólo referencias, de modo que para. Como cuando se lee un dispositivo de campo de información básica (nombre, no., ...) se transmiten
directamente, mientras que los elementos más complejos, como los programas de señal se almacenan como referencias y sólo se deben
mostrar su nombre. Sólo cuando el usuario selecciona ese elemento, el objeto se carga realmente.

Las referencias son entradas Asev que contienen una entrada de REFPATH.
El método Get para relajarse sin SHA-1 de autenticación.
6.3.1.2 actualización
Actualización establece el valor de un campo nuevo. Como una actualización de parámetros de entrada se pasa exactamente la
misma estructura que se ha proporcionado previamente con Get. También se pueden establecer referencias con esta función.
Una recolección de basura no tiene lugar, ya que los objetos pueden ser referenciados directamente en cualquier momento.
El método de actualización se ejecuta con SHA-1 de autenticación.
6.3.1.3 Crear
Los nuevos objetos se crean con "Crear". Crear obras como actualización. Los nuevos objetos se añaden desde el
dispositivo de unión de forma automática correcta. Crear recibe como entrada exactamente los mismos valores que
una actualización, simplemente no existía antes de que el objeto.
El método Create se maneja con SHA-1 de autenticación.
6.3.1.4 Eliminar
Con se eliminan Eliminar objetos. La función permite la eliminación sólo si no hay ningún objeto sobre el
tema se refiere. De lo contrario, una lista de objetos se devuelve que consiste en referencias a objetos
que todavía apuntan al candidato claro. salvará las referencias tan extensible REFPATH. El método
Delete se maneja con SHA-1 de autenticación

7 ejemplo de mapeo de mensajes XML
7.1 Tipos, descripción XML

<? Xml version = codificación "1.0" = "ISO-8859-1"?> <! DOCTYPE
octubre SISTEMA "ocit.dtd"> <OCIT_TYPE_DATEI> <OCTAVE>
<FABRICANTE> ODG </ FABRICANTE> <tipo de

dispositivo> Ejemplo </ DISPOSITIVO TIPO> <versión> 1
</ VERSION> <SUBVERSION> 1 </ SUBVERSION>
<NÚMERO dominio>
<Nombre> ZEITSTEMPEL_UTC </ NOMBRE>

<Descripción> Tiempo Universal Coordinado </ description> <miembro> 0 </
miembro> <OTYPE> 48 </ OTYPE>
<BASE TIPO NOMBRE> ULONG </ BASE TIPO NOMBRE> <MIN> 1 </
MIN>
<MAX> 0xFFFFFFFF </ MAX> <NULLVAL>
0 </ NULLVAL> <Solución> 1 </ Solución>
<UNIT> segundo </ UNIT> </ NÚMERO
dominio> <NÚMERO dominio>
<Nombre> OBJECT_ID_UBYTE </ NOMBRE>

<Descripción> identificación de un objeto </ description> <miembro> 0 </ miembro>
<BASE TIPO NOMBRE> UBYTE </ BASE TIPO NOMBRE>

<MIN> 0 </ MIN> <MAX> 0xfe </ MAX> <NULLVAL> 0xff </
NULLVAL> <Solución> 1 </ Solución> <UNIDAD /> </
NÚMERO dominio> <STRING DOMAIN >
<Nombre> OBJECT_NAME </ NOMBRE>

<Descripción> nombre de un objeto </ description> <miembro> 0 </ miembro>
<BASE TIPO NOMBRE> STRING </ BASE TIPO NOMBRE>

<MAXLEN> 255 </ MAXLEN> </ STRING dominio> <ENUMDOMAIN>
<Nombre> RetCode </ NOMBRE>

<Descripción> valor de retorno general de métodos </ description> <miembro> 0 </ miembro>
<BASE TIPO NOMBRE> USHORT </ BASE TIPO NOMBRE> <MAX>

999 </ MAX> <ENUMENTRY>
<NOMBRE> Aceptar </ name>

<Descripción> Método ejecutado con éxito </ description> <valor> 0 </ VALUE> </
ENUMENTRY> <ENUMENTRY>
<Nombre> ERROR </ NOMBRE>

<Description> Problemas comunes </ description> <valor> 1 </ value> </
<Nombre> ERR_BAD_CALLCHK </ NOMBRE>

<Descripción> BTPPL: El método era con una suma de comprobación incorrecta
llamada. </ description>
<Valor> 2 </ VALUE> </
<Nombre> ERR_BAD_CALLTIME </ NOMBRE>

<Description> BTPPL: La hora de la llamada no es derecho a 30 minutos exactamente con la
hora local del mismo. </ description>

<Nombre> ERR_BAD_RETCHK </ NOMBRE>
<Descripción> BTPPL: generada después de la transmisión desde el transmisor cuando el
no coincide con la suma de comprobación telegrama de retorno. </ description>
<Nombre> ERR_BAD_RETTIME </ NOMBRE>

<Descripción> BTPPL: generada después de la transmisión desde el transmisor cuando el tiempo
Retorno del bloque que no es cierto, pero el bloque de transmisión era el momento correcto. En este caso, el comando se ha hecho ya, pero
hay una sincronización del tiempo requerido. Si el código vuelve a aparecer después de la sincronización de tiempo, esto indica que los
hackers o error. </ Description>

<Nombre> ERR_SYNCHRONIZE </ NOMBRE>

<Descripción> BTPPL: generada después de la transmisión desde el transmisor cuando el tiempo
Retorno del bloque que está mal y el comando ya tenía un tiempo incorrecto desde el cuarto bloque de transmisión. Este código no se utiliza entre
el controlador y la oficina. </ Description>
<Nombre> err_type </ NOMBRE>

<Descripción> BTPPL: tipo, que consiste en ODG MemberID y OTYPE no es
conocido / implementado. </ description>
<Nombre> ERR_METHOD </ NOMBRE>

<Descripción> BTPPL: número especificado método no es
conocido / implementado. </ description>
<Nombre> ERR_PATH_LEN </ NOMBRE>

<Descripción> longitud de la trayectoria inesperada </ description> <valor> 16 </
VALUE> </ ENUMENTRY> <ENUMENTRY>
<Nombre> ERR_PATH_VAL </ NOMBRE>

<Descripción> No ejemplo, para la ruta dada (valor) encontrados </ description> <valor> 17 </ VALUE> </ ENUMENTRY>
<ENUMENTRY>
<Nombre> PARAM_INVALID </ NOMBRE>

<Descripción> parámetro erróneo </ description> <valor> 32 </ VALUE> </
<Nombre> INTERVALL_INVALID </ NOMBRE>

<Descripción> válido o ya especificado intervalo expirado </ description> <valor> 33 </ VALUE> </ ENUMENTRY> <ENUMENTRY>
<Nombre> NOT_CONFIGURED </ NOMBRE>

<Descripción> La función de referencia no es debido a la falta de suministro
disponible </ description>
ENUMENTRY> </ ENUMDOMAIN>
<OBJTYPE>
<Nombre> objA </ NOMBRE>

<Descripción> Ejemplo objeto A </ description> <miembro> 0 </
miembro> <OTYPE> 500 </ OTYPE> <DECL>
<NOMBRE> Tiempo </ name>

<Description> de tiempo </ description> <referencia>

DECL> <DECL>
<Nombre> no </ name>

<Descripción> Ejemplo Byte id </ description> <referencia>

<NOMBRE> OBJECT_ID_UBYTE </ name> </
<Nombre> Nombre </ name>

<Descripción> Ejemplo Nombre </ description> <referencia>

OBJECT_NAME </ name> </ REFERENCIA> </
DECL> <PATHPART>
<Nombre> PfadNr </ NOMBRE>

<Descripción> Ejemplo ruta </ description> <referencia>

OBJECT_ID_UBYTE </ name> </ REFERENCIA>
</ PATHPART>
<MAXMETHODNR> 32 </ MAXMETHODNR> </ OBJTYPE>
<OBJTYPE>
<Nombre> objB </ NOMBRE>

<Descripción> Ejemplo objeto B, derivado de objA </ description> <miembro> 0 </ miembro> <OTYPE>
501 </ OTYPE> <BASE dominio>

<NOMBRE> objA </ name> <base del
dominio /> <DECL>
<Nombre> nombreB </ NOMBRE>

<Descripción> Ejemplo Nombre B </ description> <referencia>

DECL>

<MAXMETHODNR> 64 </ MAXMETHODNR> </ OBJTYPE>
<OBJTYPE>
<Nombre> ObjC </ NOMBRE>

<Descripción> Ejemplo Object C </ description> <miembro> 0 </
miembro> <OTYPE> 502 </ OTYPE> <DECL>
<Nombre> Nombre </ name>

<Descripción> Nombre </ description>
<referencia>
DECL> <DECL>
<Nombre> objs </ NOMBRE>

<Descripción> Ejemplo incrustado como matriz polimórfica </ description> <referencia> Objetos

<NOMBRE> objA </ name> </
REFERENCIA>
<MINCOUNT> 0 </ MINCOUNT> <MaxCount> 4 </
MaxCount> <REFPATH_DATA> 3 </ REFPATH_DATA>
<EXTENSIBLE> </ EXTENSIBLE> </ DECL>

<MAXMETHODNR> 32 </ MAXMETHODNR> </ OBJTYPE> </
PTU>
</ OCIT_TYPE_DATEI>

7.2 casos
Las instancias en la unidad 5, por ejemplo:
Ruta de acceso de la unidad 5 /
Nombre ObjC =
ObjC
name = ObjA1
0x38d0dea4 nr = 17
1 = ObjA2 objA tiempo =
0x38d0dfa9 nr = 23 name
ObjA tiempo =
3
ObjB tiempo =
0x38d0dfb9 nr = 37 name
= ObjA3 nombreB =
ObjB1
7.3 Los telegramas
Solicitar telegrama para objA / 1.Get () con UDP de 0 ª central
offset Offset + 0 Offset + 1 Offset + 2 + 3
UDP
HdrLen 11 Tiempo de trabajo JobTime (Lo) 83

0 000 00 rr 0
(Hola) E6
JobTime Cnt Miembro

JobTime Cnt (Hola) 00 Miembro (Lo) 00
4 (Lo) 00 (Hola) 00
Método
OTYPE (Hola) 01 OTYPE (Lo) F4 Método (Lo) 00
8 (Hola) 00
ZNR (Hola) 00 ZNR (Lo) 00 FNº (Hola) 00 FNº (Lo) 05

12
Fletcher (Hola) Fletcher (Lo)

ruta 01
16 F1 77

El dispositivo responde con:
UDP
HdrLen 10 001 00 rr 0 Tiempo de trabajo JobTime (Lo) 83

0
(Hola) E6
JobTime Cnt JobTime Cnt

Miembro (Hola) 00 Miembro (Lo) 00
4 (Hola) 00 (Lo) 00
OTYPE (Hola) 01 OTYPE (Lo) F4 Método (Hola) 00 Método (Lo) 00

8

12
RetCode 0 RetCode 0
16 38 D0
20 DF A9 17 06
24 4F'O' 62 'B' 6A'j' 41 ''
Fletcher (Hola) Fletcher (Lo)

28 32 '2' 00 3E D4
Solicitar telegrama para ObjC.Get () con UDP de Central 0
UDP
HdrLen 10 000 00 rr 0 Tiempo de JobTime (Lo) 84

0
trabajo (iii) 15
JobTime Cnt JobTime Cnt
Miembro (Hola) 00 Miembro (Lo) 00
4 (Hola) 00 (Lo) 00
OTYPE (Hola) 01 OTYPE (Lo) F6 Método (Hola) 00 Método (Lo) 00

8

12
Fletcher (Lo)
Fletcher (Hola) A8
16 A6

El dispositivo responde con:
UDP
0 HdrLen 10 001 00 rr 0 Tiempo de JobTime (Lo) 84

trabajo (iii) 15
JobTime Cnt JobTime Cnt Miembro
Miembro (Lo) 00
4 (Hola) 00 (Lo) 00 (Hola) 00
Método
OTYPE (Hola) 01 OTYPE (Lo) F6 Método (Lo) 00
8 (Hola) 00

12
RetCode 0 RetCode 0 Nombre len 05 Nombre

16
4F'O'
20 62 'B' 6A'j' 43 'C' 00
ID.Member ID.Member (Lo)

Número 03 objs RefLen 5
24 (Hola) 00 00
ID.OTYPE (Lo)
ID.OTYPE (Hola) 01 ID.Path 00 Datalen (Hola) 00
28 F4
Datalen (Lo) 0C tiempo

32 D0 DE
38
No Nombre len 06 Nombre

36 E4
11 4F'O'
40 62 'B' 6A'j' 41 '' 31 '1'

RefLen 5
44 00 (Hola) 00 00
ID.OTYPE (Lo)
48 F4
Datalen (Lo) 0C tiempo

52 D0 DF
38
n° Nombre Len 06 Nombre

56 A9
17 4F'O'
60 62 'B' 6A'j' 41 '' 32 '2'

RefLen 5
64 00 (Hola) 00 00

ID.OTYPE (Lo)
68 F5
Datalen (Lo) 13 tiempo

72 D0 DF
38
No Nombre len 06 Nombre

76 B9
25 4F'O'
80 62 'B' 6A'j' 41 '' 33 '3'
Nombre len 06 Nombre

84 00 62 'B'
4F'O'
88 6A'j' 42 'B' 31 '1' 00
Fletcher (Lo)
Fletcher (Hola) FB
92 BA

8 opciones de seguimiento
Nota: en cuenta el estado de la versión del dispositivo de campo!
La detección del tráfico btppl-telegrama para propósitos de prueba se llama "rastreo". Hay dos
opciones:
8.1 archivo de traza
El tráfico de mensajes se detecta en el dispositivo de control de la señal luminosa o en una instalación central y se
almacena en un "archivo de seguimiento". Esta capacidad de completar la detección del tráfico de telegramas btppl en
archivos de seguimiento es obligatorio para los dispositivos de la sede y de campo.
En los módulos OCIT O Biblioteca (src_btppl_type_040701.zip) para generar los archivos de seguimiento
(btppl_trace.c y btppl_trace.h) están incluidos.
Los archivos de rastreo se pueden leer con la herramienta de tipo O OCIT (typetool_WIN _.... exe,
typetool_LINUX _....). Tiene las siguientes características:
• Leer OCIT Tipo (.dtd y .xml) y comprobar
• Tipo de representación HTML OCIT
• convertir archivo de seguimiento (archivo de seguimiento btppl binario) en texto legible
• llamadas del cliente (cliente), btppl emisión de la solicitud y responder
• característica especial: la función de servidor de objeto evlist (recepción de eventos)
8.2 Rastreo externa
El tráfico de mensajes se detecta en línea por un dispositivo de detección externo (herramienta de seguimiento) sobre los
puertos designados (puertos de rastreo estándar) en la unidad de control de señales de luz o una instalación central y se
almacena.
Una herramienta de rastreo normalmente tiene las siguientes características:
• Detectar el tráfico de telegramas btppl a través del puerto de rastreo por omisión (línea de Búsquedas)
• la visualización en línea de la traza
• aplicar archivo de seguimiento en texto legible (fuera de línea)
Conexión 8.2.1 Rastreo
El principio de conexión rastro de servidor VD (Central) y el controlador de señales de tráfico para poner
en práctica.

Estándar traza Puerto: Nombre del servicio: trace OCIT (puerto TCP 5001).
Nota: No se ha establecido la física de la conexión.
Opcional cuando la estructura de toma de corriente, un criterio de filtro puede ZNR = xxxxx y / o FNR = xxxxx se
envía desde el instrumento de análisis, pero al menos uno LF (\ n).
Ejemplos:
ZNR = 42; FNR = 23 \ n FNR =

23 \ n 42 = ZNR \ n \ n
tiempo de espera de socket: La herramienta de seguimiento debe de haber eliminado los datos dentro de 5
segundos de lo contrario la llamada se puede cerrar.
Nota: herramientas de seguimiento preferiblemente deberían estar conectados a través de sus propias
conexiones rápidas con el centro o la unidad de control de señal de luz, porque el volumen de datos se
duplica por el trazado en línea. Con uso simultáneo de la transmisión de perfiles 1 o 2 para control de
instrumentos y el rastreo de este modo los límites de la capacidad de transmisión se puede lograr.
8.3 Formato de archivo de rastreo binario
Un archivo de rastreo btppl binaria consiste en una secuencia de registros de rastreo de la estructura se describe a
continuación. Todos los datos (es decir, primero MSB, LSB pasado) escritos en orden de bytes "btppl".
nombre
tipo observación
trclen OCIT_UI4 Número de bytes del siguiente registro de rastreo.
segundo OCIT_UI4 UTC segundo cuando fue escrito registro de rastreo.
USEC OCIT_UI4 Microsegundo del segundo UTC cuando fue escrito registro
de rastreo.
IPADR btppl_ip_address Dirección IP remota.
puerto btppl_port RemotePort (NBO)
protocolo OCIT_UI1 'U' para LoPrio udp, 't' para LoPrio tcp, 'U' para HiPrio udp, 'T'
para HiPrio tcp.
Los valores de los uUtT 'describir registros derivados de

método remoto de llamadas entre el cliente y el servidor.

El valor 'x' y 'X' describe los registros que surgen debido a
las llamadas a métodos locales. Este método llama se
inician mediante la función de rastreo de BTPPL-Lib ,
dirección OCIT_UI1 '>' Por telegrama recibido, '<' para el mensaje enviado.
telegrama HdrLen, banderas ... telegrama original, tal como se transmite, se inicia con la cabecera
Fletcher
btppl.
s. Cap. 5.1.1
Los tipos de datos de la Biblioteca OCIT O:
tipo de datos Tipo de datos en C de carga máxima válida transmisión observación

rico
OCIT_UI1 unsigned 0 ... 255 transmitida como 1-byte (sin 8 bits sin signo
char alineación)
OCIT_UI2 unsigned 0 ... 65.535 2 bytes transmitidos, byte alto primero (sin 16 bits sin signo
short alineación)
OCIT_UI4 unsigned 0 ... 4294967295 de 4 bytes transmitidos, byte alto primero (sin 32 bits sin signo
long alineación)
OCIT_SI1 signed char -128 ... 127 transmitida como 1-byte (sin 8 bits con signo
alineación)
OCIT_SI2 firmado corta -32.768 32.767 ... 2 bytes transmitidos, byte alto primero (sin 16 bits con signo
alineación)
OCIT_SI4 firmado a largo -2147483648 ... de 4 bytes transmitidos, byte alto primero (sin De 32 bits con signo
2.147.483647 alineación)
btppl_ip_address unsigned 0 ... 4294967295 de 4 bytes transmitidos, byte alto primero (sin 32 bits sin signo
long alineación)
btppl_port unsigned 0 ... 65.535 2 bytes transmitidos, byte alto primero (sin 16 bits sin signo
short alineación)
estructura 8,4 aplicación
Para analizar los marcos de orden de los registros de seguimiento de, por ejemplo Liste.GetSFSince la
información en el momento de transferir la estructura de trabajo existente es necesario. Para ello, una entrada
de rastreo de la llamada al método GetListConfig () de SystemobjektFeldgeraet entró (petición y
responderemos) al principio de cada archivo de rastreo. El método no es explícitamente de una entidad externa
(por ejemplo, herramienta de seguimiento) se llama, se introduce, una estructura que tiene la información de la
orden en el archivo de seguimiento que corresponde a la devolución de la llamada GetListConfig (). Esta
llamada de método local no se transfiere a la sede o el controlador de señal de luz.
En la traza registros obtener el campo "IPADR" y "puerto" es 0, el "protocolo" tiene el valor 'x'.

Caso 1: archivo de rastreo
En los parámetros de llamada ZnrFnrFilter deben ser introducidos para FNº y ZNR cada uno del valor cero
(65535) para la configuración de todos los dispositivos de campo se introduce.
Llame parámetros ListNrs (array vacío), de modo que se introduzca la configuración de todas las listas de
variables.
Caso 2: Conexión rastro
En la llamada parámetros ZnrFnrFilter la acumulación evaluado se deben introducir los criterios de filtrado de
conexión rastro. el valor cero (65535) se debe introducir para no incluido en los valores de criterio de filtro.
Para hacer que la configuración de la lista se introduce sólo para el equipo, para el que se transfieren
registros de rastreo.
Llame parámetros ListNrs (array vacío), de modo que se introduzca la configuración de todas las listas de
variables.
En el análisis de toma de esta información de la orden se envía una vez en la construcción de socket. La corriente
a través del puerto de traza y el archivo de rastreo son idénticos en contenido y se convierte en uno al otro.

glosario
Las explicaciones de los términos técnicos especializados y abreviaturas utilizadas en este documento,
consulte el documento "OCIT - O V3.0 Glosario".
Lista de Figuras
Figura 1: estaciones remotas OCIT - Interfaces .................................................. ....................... 8
Figura 2: Las capas en el modelo de referencia OSI ISO .................................................. .......... 12
Figura 3: protocolos para OCIT estaciones remotas .................................................. ........................ 19
Figura 4: Metamodel .................................................. .................................................. ..... 39

OCIT O_Protokoll_V3.0_A01
derechos de autor • 2018 ODG

Ocit-O Protokoll v3.0 A01.de - Es PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ocit-O Protokoll v3.0 A01.de - Es PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Interfaz de comunicación abierta de Tráfico Sistemas de Control

Las interfaces abiertas para la ingeniería de tráfico

normas y protocolos OCIT

OC IT De veloper G rupo (ODG)

Documento: OCIT O_Protokoll_V3.0_A01

Editorial: OCIT desarrollador Group (ODG)

OCIT O_Protokoll_V3.0_A01 Página 2 de 67

Especificaciones ................................................. .................................................. ........ 7

1 Introducción ................................................ .................................................. .......... 8

1.1 Límites del sistema ................................................ .............................................. 8

2 interfaces y las funciones del sistema OCIT estaciones remotas ....................................... 9

2.1 Nivel central ............................................... ............................................. 10

transferencia y protocolo 2.2 Datos .............................................. .................... 10

2.3 Los dispositivos de campo ................................................ .................................................. 11 ..

3 modelo de comunicación OCIT estaciones remotas ............................................. ............ 12

3,1 asegurar la transmisión .............................................. ............................ 13

3.1.1 Algoritmo de seguridad .............................................. ...................... 13

3.1.2 Firewall .............................................. .............................................. 13

3.2 direcciones ................................................ .................................................. .... 14

3.3 red IP .............................................. .................................................. ......... 14

3.4 Rutas ................................................ .................................................. ....... 14

3.5 El tiempo ................................................ ................................................ 14

3.5.1 Hora del sistema .............................................. ......................................... 15

3.5.1.2 dispositivos de campo con conexiones intermitentes a la central 15 ...................

3.5.2 transmisión orientado a Event-............................................. ......... 16

3.5.3 Asignación de tiempo ............................................. ............................ 16

3.5.4 Tiempo de respuesta .............................................. ..................................... 16

3,6 asignación lógica ............................................... ..................................... 16

3,7 perturbar el equipo de transmisión .............................................. ............ 16

4 protocolos de transmisión ................................................ ...................................... 17

protocolo 4.1 de transmisión de la capa OSI 3 (IP) ........................................ ...... 17

OCIT O_Protokoll_V3.0_A01 Página 3 de 67

4.2.1 UDP con retroalimentación ............................................ ........................ 17

4.2.2 UDP sin realimentación ............................................ ..................... 18

4.2.3 TCP con retroalimentación ............................................ ........................ 18

4.2.4 TCP sin realimentación ............................................ ..................... 19

4.2.5 Transmisión de seguridad en el plano de transporte ............................... 19

5 protocolo OCIT estaciones remotas BTPPL (capas OSI 5-7) .................................... 19

5.1 capas de protocolo de paquetes de transporte basadas - BTPPL .......................................... 20

5.1.1 Estructura del telegrama BTPPL: ............................................ .................. 21

5.2 Cliente General de Comunicación - Servidor ............................................ ..... 23

5.2.1 cambiar el nombre de dominio de dispositivos de campo a través de un DNS. 24

5.3 Asignación Temporal (sello de tiempo) ............................................ ................... 24

5.3.1 Tiempo de espera .............................................. ............................................. 25

5,4 asignación lógica ............................................... ..................................... 25

5.5 codificación de los datos .............................................. ...................................... 25

5.6 Objetos ................................................ .................................................. ...... 26

5.6.1 Número miembro ............................................ ................................ 28

5.6.2 Identificación de objetos ............................................... ............... 28

5.6.2.1 Selección de los códigos de retorno (RetCodes) ......................................... ... 29

5.6.3 invalidación de caché DNS .......................................... ...................... 31

5,7 asegurar la transmisión en el protocolo OCIT estaciones remotas ..................... 32

5.7.1 contraseñas OCIT O ........................................... ............................... 32

5.7.1.1 La instalación de un nuevo dispositivo ........................................... .......... 33

5.7.1.2 cambio de OCIT O la contraseña de un dispositivo de campo ........................ 33

5.7.2 Transmisión de seguridad por el algoritmo Fletcher ................ 34

5.7.3 Transmisión de seguridad por el SHA-1 algoritmo ................... 35

5.7.3.1 Determinación de la suma de comprobación ............................................ ....................... 36

OCIT O_Protokoll_V3.0_A01 Página 4 de 67

5.7.3.3 Códigos de retorno utilizados por el protocolo de seguridad ........................ 38

5.8 Examen de la canal TCP ............................................ ................................. 38

6 tipificación ................................................ .................................................. ....... 39

6.1 objetos de interfaz ................................................ .................................... 39