natgillin/translations-raw huggingface dataset:
Базата от данни трябва да поддържа функция с възможност за конфигуриране на контрол за правдоподобността на данните преди да се потвърди въвеждането, актуализирането или изтриването на записи от данни.
The extension of the capacity shall not require replacement of the subsystem.
Време на отговор
Historical data
Базата от данни трябва да реагира достатъчно бързо, така че потребителите да могат оперативно да въвеждат, актуализират или изтриват записи от данни.
A database shall support the management of historical data in the meaning of making of data available that has been already transferred into an archive.
Аспекти на производителността
Back-up strategy
Справочните файлове и базите от данни трябва да осигуряват ефективно по отношение на разходите информационно търсене, необходимо за ефективно извършване на всички съответни движения на влакове, които попадат в обхвата на настоящата ТСОС.
A back-up strategy shall be in place to ensure that the complete database contents for up to a 24 hour period can be recovered.
Аспекти относно капацитета
Commercial aspects
Базата данни трябва да позволява записването на необходимите данни за всички товарни вагони по цялата мрежа.
A database system used shall be available commercially off-the-shelf (COTS-product) or be available in the public domain (Open Source).
Трябва да бъде възможно лесното увеличаване на капацитета (напр. чрез добавянето на още запаметяващи устройства и компютри).
Remarks:
Увеличаването на капацитета не трябва да налага подмяна на подсистемата.
The above requirements must be handled by a standard Database Management System (DBMS).
Данни с исторически характер
The usage of the various databases is embedded into various work flows described here before.
Базата данни трябва да позволява управление на данните с исторически характер, тоест възможността за консултиране на данните, които вече са били архивирани.
The general workflow is a request/response mechanism, where an interested party requests information from the database through the Common Interface (4.2.12.1: General Architecture and 4.2.12.6: Common Interface).
Стратегия за резервиране на данните (backup)
The DBMS responds to this request either by providing the requested data or by responding that no data can be made available (no such data exists or access is refused due to access control).
Стратегията за архивиране на данните трябва да гарантира възстановяването на всички данни максимум от последните 24 часа.
General Architecture
Търговски аспекти
This subsystem will see, over time, the growth and interaction of a large and complex Telematics rail interoperability community with hundreds of participating players (RUs, IMs, etc.), which will compete and/or cooperate in serving the market's needs.
Използваната система трябва да бъде предлаган в търговската мрежа продукт или безплатен софтуер (с отворен код).
The Network & Communication infrastructure supporting such rail interoperability community will be based on a common Information Exchange Architecture, known and adopted by all participating players.
Забележки:
The proposed Information Exchange Architecture:
Горепосочените критерии трябва да бъдат прилагани от стандартна система за управление на бази данни (DBMS).
is designed to reconcile heterogeneous information models by semantically transforming the data that is exchanged between the systems and by reconciling the business process and application-level protocol differences,
Използването на базите данни се основава на различните описани по-горе операции.
has minimum impact on the existing IT architectures implemented by every actor,
Тяхното общо функциониране се базира на механизъм от въпроси/отговори, при който потребителят подава заявка за получаване на информация от базата данни чрез общия интерфейс (глави 4.2.12.1 Цялостна архитектура и 4.2.12.6: Общ интерфейс).
safeguards IT investments made already.
Системата за управление на бази данни отговаря на тази заявка: тя или предоставя исканата информация, или отговаря, че не е налична никаква информация (информацията не съществува или достъпът до нея е отказан).
The Information Exchange Architectures favours a mostly Peer-to-Peer type of interaction between all players, while it guarantees the overall integrity and consistency of the rail interoperability community by providing a set of centralised services.
Цялостна архитектура
A Peer-to-Peer interaction model allows the best cost distribution between the different players, based on actual usage and it will present, in general, lesser scalability problems.
С течение на времето тази подсистема ще бъде изправена пред нарастване и взаимодействие на голяма и комплексна общност в областта на железопътната телематична оперативна съвместимост, със стотици участници (ЖПП, УИ ...), които ще се конкурират и/или сътрудничат при обслужване на пазарните потребности.
A pictorial representation on the general architecture is given in the document ‘TAF TSI — Annex A.5 Figures and Sequence Diagrams of the TAF TSI messages’, Chapter 1.5, listed in Appendix I.
Мрежовата и информационна инфраструктура, обезпечаваща тази общност в областта на железопътната оперативна съвместимост, ще се базира на обща архитектура на информационния обмен, известна и възприета от всички участващи партньори.
Network
Предложената архитектура на информационния обмен има следните характеристики:
Networking in this case means the method and philosophy of communication and does not mean the physical network.
проектирана е да съчетава хетерогенни информационни модели чрез семантично трансформиране на данните, които се обменят между системите, и чрез намаляване на различията между стопанските процеси и протоколите на ниво „приложение“;
Rail interoperability is based on a common Information Exchange Architecture, known and adopted by all participants, thus encouraging and lowering barriers for new entrants, especially customers.
има минимално въздействие върху съществуващите информационно-технологични (IT) архитектури, използвани от всеки от участниците;
The security issue will therefore be addressed not by the network (VPN, tunnelling, etc.), but by exchanging and managing inherently secure messages.
не засяга вече направените инвестиции в областта на информационните технологии.
A VPN network is therefore not required (the administration of a large VPN network will be complex and costly to manage), thus avoiding problems with responsibilities and ownership allocation.
Архитектурата на информационния обмен се основава най-вече на взаимодействието между всички участници от типа Peer-to-Peer, като същевременно се гарантира общата цялост и съгласуваност на действията на общността в областта на железопътната оперативна съвместимост чрез предоставяне на пакет от централизирани услуги.
Tunnelling is not considered as a necessary means for achieving the appropriate security level.
Моделът на взаимодействие Peer-to-Peer позволява да се направи най-доброто разпределение между различните участници на базата на действителното ползване на системата и като цяло ще поражда по-малко проблеми във връзка с различията в мащаба.
In any case if some players already have or want to implement various degrees of security on selected partitions of the network, they can do so.
Графично представяне на цялостната архитектура е дадено в документа „ТСОС ТПТП — Приложение А.5 Фигури и диаграми на последователността на съобщенията по ТСОС ТПТП“, глава 1.5, който документ е включен в списъка в допълнение I.
Over the public Internet network it is possible to implement a hybrid Peer to Peer model with a common interface at each actor's node and a central certificate authority.
Мрежа
Afterwards, a Peer to Peer communication is performed between involved players.
Терминът „работата в мрежа“ в настоящия текст означава метода и философията на комуникация, а не физическа мрежа.
The peer-to-peer communication is based on technical standards for the common Interface described in the document ‘TAF TSI — Annex D.2: Appendix F — TAF TSI Data and Message Model’ listed in Appendix I.
Оперативната съвместимост в железопътния транспорт се основава на обща архитектура на информационния обмен, известна и възприета от всички партньори, като по този начин се насърчава и се намаляват съответните препятствия за присъединяването на нови участници, по-специално клиентите.
To achieve a high level of security, all messages must be self-contained, which means that the information in the message is secured and the receiver can verify the authenticity of the message.
Аспектите относно сигурността не се реализират на мрежово ниво (ВЧМ — виртуална частна мрежа, тунелиране и т.н.), а чрез обмена и използването на съобщения с вътрешно присъща сигурност.
This may be solved by using an encryption and signing scheme similar to email encryption.
Следователно не е необходимо да се използва ВЧМ (управлението на този тип мрежа в толкова голям мащаб би било сложно и скъпо) и по този начин се избягват проблемите, свързани с отговорностите и разпределението на собствеността.
Encryption
Тунелирането не се счита за необходимо за постигане на подходящото ниво на сигурност.
Either asymmetric encryption or a hybrid solution based on symmetric encryption with public key protection must be used, due to the fact that sharing a common secret key among many players will fail at some point.
При все това, ако някои участници вече разполагат или желаят да въведат различни нива на сигурност в избрани сектори от мрежата, те могат да го направят.
A higher level of security is easier to achieve if every actor takes responsibility for its own pair of keys, even though a high level of integrity of the central repository (the key server) is required.
В публичната мрежа Интернет е възможно да се приложи хибриден модел Peer to Peer с общ интерфейс във всеки възел на участник и централен сертифициращ орган.
Central Repository
След това между съответните участници се осъществява комуникация от вида с равноправни възли (Peer to Peer).
The Central Repository must be able to handle:
Комуникацията от вида с равноправни възли (Peer to Peer) се базира на технически стандарти за общ интерфейс, описани в документа „ТСОС ТПТП — Приложение Г.2: Допълнение Е — Модел на данни и съобщения в ТСОС ТПТП“, включен в списъка в допълнение I.
metadata — structured data describing the content of messages,
За да се постигне високо ниво на сигурност информацията, съдържаща се в съобщенията, трябва да бъде защитена и получателят трябва да има възможност да провери тяхната автентичност.
Public Key Infrastructure (PKI),
Това осъществи чрез използването на система за криптиране и на подписи, подобно на системата, използвана за криптиране на електронна поща.
Certification Authority (CA),
Криптиране
The management of the central repository should be under the responsibility of a non-commercial co-European organisation.
Трябва да се използва или асиметрично криптиране или хибридно решение на базата на симетрично криптиране с публичен ключ, тъй като използването на един и същ секретен ключ от много участници в даден момент ще доведе до проблеми.
Where the Central Repository is in use in conjunction with the TAP TSI (2), development and changes must be in line with TAP TSI (2) in order to achieve optimum synergies.
По-високо ниво на сигурност може да се постигне лесно, ако всеки участник поеме отговорност за своя собствен чифт ключове, независимо че това налага високо ниво на цялостност на централния архив (сървъра за ключовете).
A Common Interface is mandatory for each actor in order to join the rail interoperability community.
Централен архив
A Common Interface has to be able to handle:
Централният архив трябва да осигурява:
message formatting of outgoing messages according to the metadata,
метаданни — структурираните данни, описващи съдържанието на съобщенията,
signing and encryption of outgoing messages,
инфраструктура с публичен ключ (PKI),
addressing of the outgoing messages,
сертифициращ орган (СА),
authenticity verification of the incoming messages,
Отговорността за управлението на централния архив трябва да се възложи на нетърговска общоевропейска организация.
decryption of incoming messages,
В случай, че централният архив се използва съвместно и за нуждите по ТСОС „Телематични приложения за пътнически превози“ [2], разработването на изменения трябва да бъде съгласувано с ТСОС „Телематични приложения за пътнически услуги“ [2], с оглед постигане на оптимални синергии.
conformity checks of incoming messages according to metadata,
Общият интерфейс е задължителен за всеки участник, желаещ да се присъедини към общността за оперативна съвместимост в железопътния транспорт.
handling the single common access to various databases.
Общият интерфейс трябва да може да осигурява:
Each instance of a Common Interface will have access to all the data required according the TSI within each Wagon keeper, LRU, RU, IM, etc., whether the relevant Databases are central or individual (see also document ‘TAF TSI — Annex A.5: Figures and Sequence Diagrams of the TAF TSI messages’, Chapter 1.6, listed in Appendix I).
форматиране на изходящи съобщения в съответствие с метаданните,
Where a Common Interface is in common use with the TAP TSI (2), the development and changes must be in line with TAP TSI (2), in order to achieve optimum synergies.
подписване и криптиране на изходящи съобщения,
Based on the results of authenticity verification of incoming messages, a minimum level of message acknowledgement can be implemented:
адресиране на изходящите съобщения,
positive send ACK;
проверка на автентичността на входящите съобщения,
negative send NACK.
декриптиране на входящите съобщения,
A common interface uses the information in the central repository in order to manage the above tasks.
проверки за съответствие на входящите съобщения по отношение на метаданните,
An actor may implement a local ‘mirror’ of the central repository to shorten response times.
общ единен достъп до различните бази данни.
In light of the essential requirements in Chapter 3, the functional and technical specifications of the interfaces are as follows:
Всяка инстанция на Общия интерфейс ще има достъп до всички данни, изискващи се съгласно настоящата ТСОС, в рамките на всеки ползвател на вагони, всяко водещо ЖПП, всяко ЖПП, всеки УИ и т.н., независимо дали съответните бази данни са централни или индивидуални (вж. също документа „ТСОС ТПТП — Приложение А.5 Фигури и диаграми на последователността на съобщенията по ТСОС ТПТП“, глава 1.6, който документ е включен в списъка в допълнение I).
The infrastructure subsystem includes traffic management, tracking, and navigation systems:
В случай, че даден справочен файл се използва съвместно и за нуждите по ТСОС „Телематични приложения за пътнически услуги“ [2], допълнителното разработване и измененията трябва да бъдат съгласувани с ТСОС „Телематични приложения за пътнически услуги“ [2], с оглед постигане на оптимални синергии.
technical installations for data processing and telecommunications intended for long-distance passenger services and freight services on the network in order to guarantee the safe and harmonious operation of the network and efficient traffic management.
На база резултатите от проверката за автентичност на входящите съобщения, може да бъде въведено минимално ниво на потвърждение за получено съобщение както следва:
The subsystem Telematics Applications for Freight uses the data required for operational purposes as given by the path contract, possibly completed by infrastructure restriction data, as provided by the IM.
положително потвърждение за получено съобщение,
Thus no direct interface exists between this TSI and the TSI for infrastructure.
отрицателен отговор за неполучено съобщение.
The only connection to control command and signalling is via the
Общият интерфейс управлява горепосочените задачи, като използва информацията от централния архив.
Path contract, where within the line segment description the relevant information about usable command control and signalling equipment is given, and
Участникът може да използва местен „огледален сървър“ на централния архив, за да скъси времената за реакция.
various Rolling Sock Reference Databases, where the command control and signalling equipment of the rolling stock must be stored.
В светлината на съществените изисквания в глава 3, функционалните и технически спецификации на интерфейсите са както следва:
The subsystem Telematics Applications for freight identifies the technical and operational data, which must be available for the rolling stock.
Инфраструктурната подсистема включва системите за управление на движението, проследяване и навигация:
The rolling stock TSI specifies the characteristics of a wagon.
технически устройства за обработка на данни и телекомуникации, предназначени за използване при услугите по превоз на пътници и товари на далечно разстояние по железопътната мрежа, с оглед да се гарантира безопасна и безпроблемна експлоатация на железопътната мрежа, както и ефективното управление на движението.
If the characteristics changes for a wagon, this must be updated in the Rolling Stock Reference Databases within the normal maintenance process for the database.
Подсистемата „Телематични приложения за товарни превози“ използва необходимите за оперативни цели данни, както са посочени в маршрутния договор, с възможни допълнения от данни за ограниченията на инфраструктурата, както са дадени от УИ.
Thus no direct interface exists between this TSI and the TSI for rolling stock.
Следователно не съществува пряк интерфейс между настоящата ТСОС и ТСОС„Инфраструктура“.
The subsystem Operation and Traffic Management specifies the procedures and related equipment enabling a coherent operation of the different structural subsystems, both during normal and degraded operation, including in particular train driving, traffic planning and management.
Единствената връзка с ТСОС „Контрол/управление и сигнализация“ е посредством
The subsystem Telematics Applications for Freight mainly specifies applications for freight services including real-time monitoring of freight and trains and the management of connections with other modes of transport.
маршрутния договор, в който е дадена съответната информация относно оборудването за контрол, управление и сигнализация, използвано в съответния участък от линията, и
In order to ensure consistency between both TSIs, the following procedure applies.
разни справочни бази данни за подвижния състав, в които трябва да се съхраняват данните относно оборудването за контрол, управление и сигнализация на подвижния състав.
When the specifications of the TSI Operation and Traffic Management related to the requirements of this TSI will be written and/or will become subject to amendments, then the body in charge of this TSI must be consulted.
В подсистемата „Телематични приложения за превоз на товари“ се идентифицират техническите и оперативните данни, които трябва да бъдат на разположение по отношение на подвижния състав.
In the case that the specifications of this TSI related to operational requirements specified in the TSI Operation and Traffic Management should be subject to any amendment, the body in charge of the TSI Operation and Traffic Management must be consulted.
В ТСОС „Подвижен състав“ са определени характеристиките на даден вагон.
Interface
Когато те се променят, справочните бази данни относно подвижния състав трябва да бъдат актуализирани в съответствие с процедурата, прилагана относно поддръжката на базите данни.
Reference Telematics Applications for Freight TSI
Следователно не съществува никакъв пряк интерфейс между настоящата ТСОС и ТСОС „Подвижен състав“.
Reference Telematics Applications for passengers TSI
Подсистемата „Експлоатация и управление на трафика“ уточнява процедурите и съответното оборудване, позволяващи съгласуваното взаимодействие на различните структурни подсистеми както при нормално, така и при влошено функциониране, и основно засяга управлението на влаковете, планирането и управлението на трафика.
Train ready
Подсистемата „Телематични приложения за превоз на товари“ включва главно приложенията, свързани с услугите по превоз на товари, по-специално мониторинга в реално време на товарите и влаковете и управлението на връзките с други видове транспорт.
Train ready message
С цел осигуряване на съгласуваното функциониране на двете ТСОС се прилага следната процедура.
Train ready message for all trains
Когато се съставят и/или изменят спецификации към ТСОС „Експлоатация и управление на движението“, свързани с разпоредбите на настоящата ТСОС, трябва да се провеждат консултации с органа, отговарящ за настоящата ТСОС.
Train running forecast
Също така в случай на промяна на спецификациите на настоящата ТСОС, свързани с разпоредбите, определени в ТСОС „Експлоатация и управление на движението“, трябва да се провеждат консултация с органа, отговарящ за ТСОС „Експлоатация и управление на движението“.
Train running forecast message
Интерфейс
‘Train running forecast’ message for all trains
Точка в ТСОС „Телематични приложения за товарни превози“
Train running information
Точка в ТСОС „Телематични приложения за пътнически превози“
‘Train running information’ message for all trains
Влакът е готов
Train running interrupted to RU
Съобщение „Влакът е готов“
Train running interrupted
Съобщение „Влакът е готов“ за всички видове влакове
‘Train running interrupted’ message for all trains
Прогноза за движението на влака
Handling of short term timetable data
Съобщение за прогноза за движението на влака
Handling of short term timetable data for trains
Съобщение „Прогноза за движението на влака“ за всички видове влакове
Common interface for RU/IM communication
Съобщение с информация за движението на влака
Central repository
Съобщение „Информация за движението на влака“ за всички видове влакове
Reference files
Съобщение до УИ за прекъснато движение на влака
In light of the essential requirements in Chapter 3, the operating rules specific to the subsystem concerned by this TSI are as follows:
Прекъснато движение на влака
For data quality assurance purposes, the originator of any TSI message will be responsible for the correctness of the data content of the message at the time when the message is sent.
Съобщение „Прекъснато движение на влака“ за всички видове влакове
Where the source data for data quality assurance purposes is available from the databases provided as part of the TSI, the data contained within those databases must be used for data quality assurance.
Третиране на краткосрочни данни относно разписанието
Where the source data for data quality assurance purposes is not provided from the databases provided as part of this TSI, the originator of the message must make the data quality assurance check from their own resources.
Третиране на краткосрочни данни относно разписанието на влаковете
Data quality assurance will include comparison with data from databases provided as part of this TSI as described above plus, where applicable, logic checks to assure the timeliness and continuity of data and messages.
Общ интерфейс за комуникации ЖПП/УИ
Data are of high quality if they are fit for their intended uses, which means they
Централен архив
are Error free:
Справочни файлове
accessible, accurate, timely, complete, consistent with other sources, etc., and
Във връзка със съществените изисквания в глава 3, по-долу са представени правилата относно експлоатацията на подсистемата, разгледана в настоящата ТСОС.
possess desired features:
С цел осигуряване на качеството на данните, авторът на дадено съобщение носи отговорност за верността на данните в съобщението към момента на изпращането му.
relevant, comprehensive, proper level of detail, easy-to-read, easy-to-interpret, etc.
Когато изходните данни, които могат да послужат за целите на осигуряване на качеството, са налични в базите данни, предоставени с ТСОС, необходимо е за осигуряване на качеството на данните да бъдат използвани именно данните от тези бази данни.
The data quality is mainly characterised by:
Ако в предоставените с ТСОС бази данни липсват такива изходни данни, които да послужат за осигуряване на качеството, авторът на съобщението трябва да провери качеството на данните въз основа на свои собствени ресурси.
Accuracy,