natgillin/translations-raw huggingface dataset:
Справочните файлове и базите от данни трябва да осигуряват ефективно по отношение на разходите информационно търсене, необходимо за ефикасното извършване на всички съответни движения на влакове, които попадат в обхвата на настоящата ТСОС.
The reference files and databases shall support in a cost effective manner the queries necessary to allow the effective operation of all relevant train runs that are covered by the provisions of this TSI.
Аспекти относно капацитета
Capacity aspects
Базата от данни трябва да осигурява съхранението на съответните данни за всички пътнически вагони и/или за мрежата.
A database shall support the storage of the relevant data for all passenger wagons and/or the network.
Трябва да бъде възможно лесното увеличаване на капацитета (напр. чрез добавянето на още запаметяващи устройства и компютри).
It shall be possible to extend the capacity by simple means (i.e. by adding more storage capacity and computers).
Увеличаването на капацитета не трябва да налага подмяна на подсистемата.
The extension of the capacity shall not require replacement of the subsystem.
Данни с исторически характер
Historical data
Базата от данни трябва да осигурява управлението на данните с исторически характер, като предоставя данни, които вече са прехвърлени в архив.
A database shall support the management of historical data by making data available that have been already transferred into an archive.
Стратегия за запазване на данните
Back-up strategy
Стратегията за запазване на данните чрез изготвяне на копие от тях трябва да гарантира, че всички данни могат да бъдат възстановени в срок до 24 часа.
A back-up strategy shall be in place to ensure that the complete database contents for a period of up to 24 hours can be recovered.
Търговски аспекти
Commercial aspects
Използваната система за управление на бази от данни трябва да бъде предлаган на пазара готов продукт (COTS) или безплатен софтуер (с отворен код).
The database system used shall be available commercially off-the-shelf (COTS-product) or be available in the public domain (Open Source).
Аспекти, свързани с неприкосновеността на личния живот
Privacy aspects
Базата от данни трябва да изпълнява изискванията на политиката на държавата-членка, в която е установено дружеството, извършващо услугата, за неприкосновеност на личния живот.
A database has to fulfil the privacy policy requirements of the Member State in which the company performing the service is domiciled.
В точка 4.2.21 „Свързване в мрежа и комуникация“ се описва комуникационната мрежа, която трябва да се използва за обмен на данни.
The description in Section 4.2.21 — Networking and communication — presents the communication network to be used for data exchange.
Тази мрежа и описаните с нея мерки за сигурност позволяват осъществяването на всякакви видове мрежови комуникации като електронна поща, обмен на файлове (FTP, HTTP) и др. Следователно страните, участващи в информационния обмен, могат сами да решат какъв вид комуникация ще изберат за целите на електронното предаване на документи — например по протокола FTP.
This network and the described security handling allow any type of network transmission, such as e-mail, file transfer (Ftp, Http), etc. The parties involved in the information exchange can then decide on the type to choose, thereby ensuring the electronic transmission of documents, for example, via FTP.
Свързване в мрежа и комуникация
Networking and communication
Обща архитектура
General architecture
С течение на времето тази подсистема ще трябва да обслужва нарастваща обширна общност със сложна структура за телематична оперативна съвместимост в железопътния транспорт, включваща взаимодействия между хиляди участници (железопътни предприятия, управители на инфраструктура, трети страни, като например търговци на дребно и публични органи, и т.н.), които ще се конкурират и/или ще си сътрудничат, за да отговарят на нуждите на пазара.
Over time this subsystem will see the growth and interaction of a large and complex telematics rail interoperability community with thousands of participating actors (railway undertakings, infrastructure managers, third parties such as retailers and public authorities, etc.), which will compete and/or cooperate in serving the market’s needs.
Инфраструктурата от мрежи и комуникации, обезпечаваща тази общност за оперативна съвместимост в железопътния транспорт, ще бъде базирана на обща „архитектура на информационния обмен“, която е известна и възприета от всички участници в нея.
The network and communication infrastructure supporting such a rail interoperability community will be based on a common ‘Information Exchange Architecture’, known and adopted by all those participating in it.
Предложената „архитектура на информационния обмен“:
The proposed ‘Information Exchange Architecture’:
е проектирана да осигурява съвместната работа на хетерогенни информационни модели чрез семантично преобразуване на данните, които се обменят между системите, и чрез преодоляване на различията в бизнес процесите и протоколите на ниво приложение,
is designed to reconcile heterogeneous information models by semantically transforming the data that are exchanged between the systems and by reconciling the differences in business processes and application-level protocols,
оказва минимално въздействие върху съществуващите информационно-технологични (ИТ) архитектури, използвани от всеки от участниците,
has a minimal impact on the existing IT architectures implemented by each actor,
гарантира възползването от вече направените инвестиции в областта на информационните технологии.
safeguards IT investments already made.
Архитектурата на информационния обмен се основава главно на взаимодействието между всички участници посредством мрежа от равноправни възли за комуникация „от точка до точка“ (Peer-to-Peer), като същевременно се гарантира общата цялост и съгласуваност на действията на общността за оперативна съвместимост в железопътния транспорт чрез предоставяне на набор от централизирани услуги.
The Information Exchange Architecture favours a mostly Peer-to-Peer type of interaction between all actors, while guaranteeing 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 distribution of costs between the different actors, based on actual usage and, in general, will pose fewer scalability problems.
Мрежата трябва да осигурява необходимото равнище на сигурност, резервен капацитет, управление на трафика, статистически инструменти, нарастване на лентата на пропускане, достъпност за потребителите и ефикасно управление.
The network shall ensure the necessary level for security, redundancy, traffic control, statistics tools, bandwidth growth, user accessibility and efficient management.
„Мрежа“ в този контекст означава методът и философията на комуникация, а не физическата мрежа.
‘Network’ in this context means the method and philosophy of communication and does not refer to 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.
Най-напред потребителят се обръща към централния регистър за получаване на метаинформация, като например за самоличността на участника, в компютъра на който е съхранена някаква информация, или за да се проверят сертификатите за сигурност.
First, the central Repository is approached to obtain meta-information, such as the identity of the peer (actor) on which information is stored, or to verify security credentials.
След това се осъществява комуникация „от точка до точка“ между съответните участници.
Afterwards, Peer-to-Peer communication takes place between the actors involved.
Протоколи
Protocols
При разработките могат да се използват само протоколи, предназначени за интернет (общоизвестни като TCP/IP, UDP/IP и т.н.).
Only protocols belonging to the Internet Protocol Suite (commonly known as TCP/IP, UDP/IP, etc.) may be used for developments.
Освен равнището на сигурност, гарантирано на нивото на мрежата (вж. точка 4.2.21.2 „Мрежа“), може да се реализира допълнително равнище на повишена сигурност за чувствителни данни чрез използване на комбинация от криптиране, схема за сертифициране и технологии за виртуални частни мрежи (VPN).
On top of the security level guaranteed at the level of the network (see Section 4.2.21.2 Network), an additional level of security can be achieved for sensitive data by using a combination of encryption, certification scheme and VPN technologies.
За предаването и съхранението на данните може да се използва асиметрично или симетрично криптиране в зависимост от изискванията на стопанската дейност.
Either asymmetric or symmetric encryption can be used for data transmission and storage, depending on the business requirements.
За целта трябва да бъде изградена инфраструктура за публични ключове (PKI).
For this purpose a public key infrastructure (PKI) is to be implemented.
Централен регистър
Central repository
Централният регистър трябва да осигурява:
The central repository must be able to handle:
метаданни — структурираните данни, описващи съдържанието на съобщенията,
metadata — structured data describing the content of messages,
списък на електронни адреси, на които участниците, за които е предназначена настоящата ТСОС, предоставят на други участници информация или данни съгласно разпоредбите на настоящата ТСОС,
list of electronic addresses where the actors addressed by this TSI allow other actors to obtain information or data according to the provisions of this TSI,
криптиране,
encryption,
удостоверяване на автентичността,
authentication,
справочник („телефонен указател“), който съдържа цялата необходима информация за участниците в обмена на съобщения и данни.
directory (phonebook) — it contains all necessary information on those participating in exchanging messages and data.
Когато централният регистър се използва във връзка с ТСОС „Телематични приложения за превоз на товари“ (TAF TSI), развитието му и измененията в него трябва да са съобразени в максималната възможна степен с тази вече прилагана ТСОС, за да се постигне оптимална синергия.
Where the Central Repository is in use in conjunction with the TAF TSI, development and changes shall be performed as closely as possible to the implemented TAF TSI in order to achieve optimum synergies.
Общ интерфейс за комуникации ЖПП/УИ
Common interface for RU/IM communication
Общият интерфейс е задължителен за всички участници, които желаят да се присъединят към общността за оперативна съвместимост в железопътния транспорт.
The common interface is mandatory for each actor in order to join the rail interoperability community.
Общият интерфейс трябва да осигурява:
The common interface has to be able to handle:
форматирането на изходящи съобщения съгласно метаданните,
message formatting of outgoing messages according to the metadata,
подписването и криптирането на изходящи съобщения,
signing and encryption of outgoing messages,
адресирането на изходящи съобщения,
addressing of outgoing messages,
проверката на автентичността на входящи съобщения,
authenticity verification of incoming messages,
декриптирането на входящи съобщения,
decryption of incoming messages,
проверките за съответствие на входящи съобщения по отношение на метаданните,
conformity checks of incoming messages according to the metadata,
общия единен достъп до различните бази от данни.
handling the single common access to the various databases.
Всички потребители на общия интерфейс ще имат достъп до всички данни, изисквани съгласно ТСОС в рамките на всяко железопътно предприятие, управител на инфраструктура и др., независимо дали съответните бази от данни са централни или индивидуални.
Each instance of the common interface will have access to all the data required according to the TSI within each railway undertaking, infrastructure manager, etc., whether the relevant databases are central or individual.
Въз основа на проверката на автентичността на входящите съобщения може да се въведе следното минимално ниво на признаване автентичността на съобщението:
Based on the results of verification of the authenticity of incoming messages, a minimum level of message acknowledgement can be implemented:
положителен резултат: изпраща се съобщение (ACK) за признаване;
positive: send ACK;
отрицателен резултат: изпраща се съобщение (NACK) за непризнаване.
negative: send NACK.
Общият интерфейс управлява горепосочените задачи, като използва информацията от централния регистър.
The common interface uses the information in the Central Repository in order to manage the above tasks.
Ако някой участник създаде местно „огледално“ копие на централния регистър, този участник трябва тогава със собствени средства да гарантира, че това копие напълно съвпада с централния регистър по точност и актуалност на данните.
If an actor implements a local ‘mirror’ of the Central Repository, that actor must then — by its own means — ensure that the local ‘mirror’ is an accurate and up to date copy of the Central Repository.
Когато общият интерфейс се използва съвместно във връзка с ТСОС „Телематични приложения за превоз на товари“ (TAF TSI), развитието му и измененията в него трябва да са съобразени в максималната възможна степен с тази вече прилагана ТСОС, за да се постигне оптимална синергия.
Where the Common Interface is in common use with the TAF TSI, the development and changes shall take place as closely as possible to the implemented TAF TSI, in order to achieve optimum synergies.
Управление на връзката с други видове транспорт
Management of connection with other modes of transport
С оглед на управление на връзката с други видове транспорт следва да се прилагат следните стандарти за предоставянето на информация и за информационен обмен с други видове транспорт:
In order to manage the connection with other modes of transport, the following standard should be applied for the provision of information to and exchange of information with other modes of transport:
за обмена на информация за разписанията между железопътни предприятия и други видове транспорт: стандартите EN 12896 (Transmodel) и EN TC 278 WI 00278207 (IFOPT — Identification of Fixed Objects in Public transport — Идентификация на неподвижни обекти в обществения транспорт),
For the exchange of timetable information between railway undertakings and other modes of transport: norms EN 12896 (‘Transmodel’) and EN TC 278 WI 00278207 (‘IFOPT — Identification of Fixed Objects in Public transport’),
за обмена на специфични данни за разписанията — техническите стандарти XML и протоколи въз основа на Transmodel, по-конкретно стандарта EN 15531 (SIRI) за обмена на разписания в реално време и стандарта EN TC 278 WI 00278207 (IFOPT) за обмена на данни за спирките и гарите,
For the exchange of specific timetable data, the XML technical standards and protocols based on Transmodel, in particular norm EN 15531 (‘SIRI’) for the exchange of real-time timetables and norm EN TC 278 WI 00278207 (‘IFOPT’) for the exchange of ‘stop/station’ data.
за обмена на тарифни данни: съответният стандарт все още е отворен въпрос (вж. приложение II — списък на отворените въпроси).
For the exchange of tariff data: this standard is still an open point (see Annex II — List of open points).
С оглед на техническата съвместимост интерфейсите на подсистема „Телематични приложения за пътнически услуги“ с другите подсистеми са съгласно посоченото в следните параграфи:
From the standpoint of technical compatibility, the interfaces of the subsystem ‘telematics applications for passenger services’ with the other subsystems are as described in the following paragraphs.
Интерфейси с подсистемата „Подвижен състав“
Interfaces with the Rolling Stock Subsystem
Интерфейси с подсистемата „Подвижен състав“
Interfaces with the Rolling Stock subsystem
Препратка към ТСОС „Телематични приложения за пътнически услуги“
Reference Telematics Applications for passengers TSI
Препратка към ТСОС „Подвижен състав“ за конвенционалната железопътна система
Reference Conventional Rail Rolling Stock TSI’s
Бордово устройство с дисплей
Board device display
Третиране на предоставянето на информация в зоната на превозните средства
Handling of information provision in vehicle area
Информация за клиентите (лица с намалена подвижност)
Customer information (PRM)
Автоматично гласово оповестяване
Automatic voice and announcement
Аудиосистема за осведомяване на пътниците
Public address system
Интерфейси с подсистемата „Телематични приложения за превоз на товари“
Interfaces with the Telematics Applications for Freight Subsystem
Интерфейс с подсистемата „Телематични приложения за превоз на товари“
Interfaces with the Telematics Applications for Freight subsystem
Препратка към ТСОС „Телематични приложения за превоз на товари“ за конвенционалната железопътна система
Reference Conventional Rail Telematics Applications for Freight TSI
Влак готов
Train ready
Съобщение „Влак готов“ за всички влакове
Train ready message for all trains
Съобщение „Влак готов“
Train ready message
Прогноза за движението на влака
Train running forecast
Съобщение „Предвиждане за движението на влака“ за всички влакове
‘Train running forecast’ message for all trains
Съобщение за предвиждане за движението на влака
Train running forecast message
Съобщение за информиране относно движението на влака
Train running information
Съобщение „Информация относно движението на влака“ за всички влакове
‘Train running information’ message for all trains
Съобщаване на ЖПП за прекъсване на движението на влака
Train running interrupted to RU
Съобщение „Прекъсване на движението на влака“ за всички влакове
‘Train running interrupted’ message for all trains
Прекъсване на движението на влака
Train running interrupted
Третиране на краткосрочни данни относно разписанието
Handling of short term timetable data
Заявка за маршрут
Path Request
Общ интерфейс
Common Interface
Централен регистър
Central Repository
Справочни файлове
Reference Files
С оглед на съществените изисквания, описани в глава 3, за експлоатацията на подсистемата, за която се отнася настоящата ТСОС, са прилагат следните специфични правила:
In the light of the Essential Requirements in Chapter 3, the operating rules specific to the subsystem concerned by this TSI are as follows:
За да се осигури качеството на данните, за всяко съобщение съгласно ТСОС неговият автор ще носи отговорност за точността на съдържащите се в съобщението данни към момента на изпращането му.
For the purposes of data quality assurance, 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 are 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 supplied by the databases provided as part of this TSI, the originator of the message must carry out 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 that they:
не съдържат грешки са достъпни, точни, навременни, пълни, в съответствие с данните от други източници и т.н.,
are error-free accessible, accurate, timely, complete, consistent with other sources, etc.,
притежават желаните характеристики актуални, пълни, достатъчно подробни, лесни за четене и за тълкуване и т.н.
possess the desired features relevant, comprehensive, proper level of detail, easy-to-read, easy-to-interpret, etc.
Основните характеристики за качеството на данните са:
The main characteristics of data quality are:
точност,
accuracy,
пълнота,
completeness,
непротиворечивост,
consistency,
актуалност.
timeliness.
Събирането на необходимата информация (данни) трябва да бъде с възможно най-малки разходи.
The information (data) required needs to be captured as economically as possible.
Това може да се постигне единствено с еднократно записване на първичните данни, ако това е възможно.
This is only feasible if the Primary Data only are recorded, if possible, on one single occasion.
Поради това първичните данни следва да бъдат въвеждани в системата колкото е възможно по-близо до своя източник, така че да са изцяло на разположение за всякакви последващи операции на обработка.
Therefore, the Primary Data should be introduced into the system as close as possible to its source, so that they can be fully integrated into any subsequent processing operation.
Преди да се изпрати съобщението, трябва да се проверят неговата пълнота и синтаксис, като за целта се използват метаданните.
Before sending out messages, the completeness and syntax must be checked using the Metadata.
Благодарение на това също така се избягва ненужния информационен трафик по мрежата.
This also avoids unnecessary information traffic on the network.
Пълнотата на всички входящи съобщения също трябва да бъде проверявана въз основа на метаданните.
All incoming messages must also be checked for completeness using the Metadata.
Непротиворечивост
Consistency
Трябва да бъдат въведени правила за осъществяване на дейността, за да се гарантира непротиворечивостта на съобщенията.
Business rules must be implemented in order to guarantee consistency.
Следва да се избягва двойното въвеждане и да се гарантира, че притежателят на данните е ясно идентифициран.
Double entry should be avoided and the owner of the data should be clearly identified.
Начинът на прилагане на тези правила зависи от тяхната сложност.
The type of implementation of these business rules depends on their complexity.
По отношение на простите правила са достатъчни ограниченията и разпоредбите, прилагани относно базите от данни.
For simple rules, database constraints and triggers are sufficient.
Когато правилата са по-сложни при използване на данни от различни таблици, трябва да се прилагат процедури за проверка на версията на данните за непротиворечивост, преди да бъдат генерирани използваните за интерфейс данни и се възприеме за ползване новата версия на данните.
In the case of more complex rules, which require data from various tables, validation procedures must be implemented which check the consistency of the data version before interface data are generated and the new data version becomes operational.
Трябва да се гарантира валидирането на предадените данни спрямо определените правила за осъществяване на дейността.
It must be ensured that transferred data are validated against the defined business rules.
Своевременното предоставяне на информация е от важно значение.
Providing information right on time is important.