natgillin/translations-raw huggingface dataset:
Всяка страна защитава националните си системи от неправомерно използване, зловредни програми, вируси, проникване в компютрите, нарушавания и незаконна промяна на данните и други подобни действия, извършени от трети страни.
Each party shall protect its own national systems against illicit use, malicious code, viruses, computer intrusions, infringements and illegal tampering of data and other comparable actions by third parties.
Страните се съгласяват да положат разумни от икономическа гледна точка усилия, за да избегнат предаването на каквито и да било вируси, времеви бомби, компютърни червеи или подобни елементи, или каквито и да било изпълними компютърни програми, които могат да окажат въздействие на компютърните системи на другата страна.
The parties agrees to use commercially reasonable efforts to avoid the transmission of any viruses, time bombs, worms or similar items or any computer programming routines that may interfere with other Party's computer systems.
Договарящите страни поемат своите разходи за разработка и експлоатация, свързани със системите и процедурите им за данни, така че да са в състояние да изпълнят задълженията си, произтичащи от настоящото допълнение.
The contracting parties shall bear their own development and operation costs in conjunction to their own data systems and procedures as required to fulfil the obligations according to this Appendix.
Услугите, посочени в поддопълнение 4.1 и предоставяни от централния възел, са безплатни.
The services specified in Sub-appendix 4.1, provided by the central hub, are free of charge.
Страните могат да възлагат за подизпълнение всяка от услугите, за които отговарят по силата на настоящото допълнение.
The parties may subcontract any of the services for which they are responsible under this Appendix.
Възлагането на подизпълнители не освобождава страната от отговорността по силата на настоящото допълнение, включително отговорността за подходящото ниво на обслужване в съответствие с поддопълнение 4.6.
Such subcontracting does not relieve the party from the responsibility pursuant to this Appendix, including the responsibility for the appropriate level of service in accordance with Sub-appendix 4.6.
Поддопълнение 4.1
Sub-appendix 4.1
Общи аспекти на TACHOnet
General aspects of TACHOnet
TACHOnet е електронна система за обмен на информация между договарящите страни по AETR, свързана с картите на водачи.
TACHOnet is an electronic system for the exchange of information on driver cards between AETR contracting parties.
TACHOnet насочва исканията за информация от запитващите страни до отговарящите страни, а отговорите на вторите до запитващата страна.
TACHOnet routes the requests for information from the requesting parties to the responding parties, as well as the replies from the latter to the former.
Договарящите страни, бидейки част от TACHOnet, трябва да свържат към системата националните си регистри за картите на водачи.
Contracting parties being part of TACHOnet must connect their national registers on driver cards to the system.
Съобщителната система TACHOnet се състои от следните части:
TACHOnet messaging system shall be composed of the following parts:
Централен възел, който е в състояние да получи запитване от запитващата страна, да го валидира и да го обработи, като го препрати на отговарящите страни.
A central hub, which shall be able to receive a request from the requesting party, validate it and process it by forwarding it to the responding parties.
Централният възел трябва да изчака всяка отговаряща страна да отговори, обединява всички отговори и изпраща обединения отговор на запитващата държава членка.
The central hub shall wait for each responding party to answer, consolidate all the answers and forward the consolidated response to the requesting Party.
Национални системи на страните, които да са снабдени с интерфейс, способен както да изпраща запитвания до централния възел, така и да получава съответните отговори.
National systems of the parties, which shall be fitted with an interface capable of both sending requests to the central hub and receiving the corresponding replies.
Националните системи могат да използват собствено или закупено програмно осигуряване за изпращането и получаването на съобщения от централния възел.
National systems may use propriety or commercial software to transmit and receive messages from the central hub.
Централният възел се управлява от Комисията, която отговаря за техническата експлоатация и поддръжката на централния възел.
The central hub shall be managed by the European Commission, which shall be responsible for the technical operation and maintenance of the central hub.
Централният възел не трябва да съхранява данни за период, по-дълъг от шест месеца, освен данните за достъп и статистическите данни, определени в поддопълнение 4.7.
The central hub shall not store data for a period exceeding six months, other than the logging and statistical data set out in Sub-appendix 4.7.
Централният възел не предоставя достъп до лични данни, с изключение на упълномощени служители на Европейската комисия, когато това е необходимо за целите на мониторинга, поддръжката и отстраняването на неизправности.
The central hub shall not provide access to personal data, except for authorised European Commission personnel, when necessary for the purpose of monitoring, maintenance and troubleshooting.
Всяка договаряща страна отговаря за:
Each contracting party shall be responsible for:
Изграждането и управлението на своите национални системи, включително на интерфейса с централния възел.
The set-up and management of their national systems, including the interface with the central hub.
Монтажа и поддръжката на своята национална система, както по отношение на апаратната част, така и на програмното осигуряване, независимо дали са собствени или закупени.
The installation and maintenance of their national system, both hardware and software, whether proprietary or commercial.
Правилната оперативна съвместимост на националната им система с централния възел, включително управлението на съобщенията за грешка, получени от централния възел.
The correct interoperability of their national system with the central hub, including the management of error messages received from the central hub.
Вземане на всички мерки за осигуряване на поверителността, целостта и наличието на информацията.
Taking all the measures to ensure the confidentiality, integrity and availability of the information.
Работата на националните системи в съответствие с нивата на обслужване, определени в поддопълнение 4.6.
The operation of the national systems in accordance with the service levels set out in Sub-appendix 4.6.
Поддопълнение 4.2
Sub-appendix 4.2
Функционални възможности на TACHOnet
Functionalities of TACHOnet
Съобщителната система TACHOnet трябва да разполага със следните функционални възможности:
The following functionalities shall be provided through TACHOnet messaging system:
Check Issued Cards (проверка за издадени карти) (CIC): позволява на запитващата страна да изпрати Check Issued Cards Request (запитване за проверка за издадени карти) до една или до всички отговарящи държави членки, за да се определи дали даден заявител за карта вече притежава карта на водач, издадена от отговарящите страни.
Check Issued Cards (CIC): allows the requesting party to send a Check Issued Cards Request to one or all responding parties, in order to determine if a card applicant already possesses a driver card issued by the responding parties.
Отговарящите страни отговорят чрез Check Issued Cards Response (отговор на запитване за проверка за издадени карти).
The responding parties shall reply to the request by sending a Check Issued Cards Response.
Check Card Status (проверка на статуса на карта) (CCS): позволява на запитващата страна да поиска от отговарящата страна подробности за карта, издадена от втората, като изпрати Check Card Status Request (запитване за проверка на статуса на карта).
Check Card Status (CCS): allows the requesting party to ask the responding party about the details of a card issued by the latter by sending a Check Card Status Request.
Отговарящата страна отговоря на запитването чрез Check Card Status Response (отговор на запитване за проверка на статуса на карта).
The responding party shall reply to the request by sending a Check Card Status Response.
Modify Card Status (промяна на статуса на карта) (MCS) позволява на запитващата страна да уведоми отговарящата страна чрез Modify Card Status Request (запитване за промяна на статуса на карта), че в статуса на дадена карта, издадена от втората, е настъпила промяна.
Modify Card Status (MCS): allows the requesting party to notify the responding party, through a Modify Card Status Request, that the status of a card issued by the latter has changed.
Отговарящата страна отговоря чрез Modify Card Status Acknowledgement (потвърждение на промяната на статуса на карта).
The responding party shall reply with a Modify Card Status Acknowledgement.
Issued Card Driving Licence (издадена карта срещу свидетелство за управление) (ICDL): позволява на запитващата страна да уведоми отговарящата страна чрез Issued Card Driving Licence Request (запитване за издадена карта срещу свидетелство за управление), че първата е издала карта срещу свидетелство за управление, издадено от втората.
Issued Card Driving Licence (ICDL): allows the requesting party to notify the responding party, through an Issued Card Driving Licence Request, that a card has been issued by the former against a driving licence issued by the latter.
Отговарящата страна отговоря чрез Issued Card Driving Licence Response (отговор за издадена карта срещу свидетелство за управление).
The responding party shall reply with an Issued Card Driving Licence Response.
Трябва да бъдат включени и други видове съобщения, които се считат за подходящи за ефективното функциониране на TACHOnet, като например уведомления за грешка.
Other message types deemed suitable for the efficient functioning of TACHOnet shall be included, for instance error notifications.
Националните системи трябва да разпознават статусите на картата, изброени в таблица 1, когато се използва някоя от функционалните възможности, описани в точка 1.
National systems shall recognise the card statuses listed in Table 1, when using any of the functionalities described in point 1.
Същевременно страните не са длъжни да въведат административна процедура, която да използва всички изброени статуси.
However, parties are not required to implement an administrative procedure that makes use of all of the listed statuses.
Когато дадена страна получи отговор или уведомление за статус, който не се използва в административните ѝ процедури, националната система трябва да преобразува статуса от полученото съобщение в подходяща стойност за въпросната процедура.
When a party receives a response or notification giving a status that is not used in its administrative procedures, the national system shall translate the status on the received message to the appropriate value in that procedure.
Отговарящата страна не отхвърля съобщението, ако статусът от съобщението фигурира в таблица 1.
The message shall not be rejected by the responding party, as long as the status in the message is listed in Table 1.
Статусът на карта, включен в таблица 1, не трябва да се използва за определяне на това дали дадена карта на водач е валидна за управлението на МПС.
The card status listed in Table 1 shall not be used to determine if a driver card is valid for driving.
Когато чрез функционалната възможност CCS дадена страна изпраща запитване до регистъра на страната, издала картата, отговорът трябва да съдържа специалното за целта поле „валидна за управление“.
When a party queries the register of the card issuing national authority via the CCS functionality, the response shall contain the dedicated field ‘valid for driving’.
Националните административни процедури трябва да са такива, че отговорите на CCS винаги да съдържат правилната стойност на „валидна за управление“.
The national administrative procedures shall be such that CCS responses always contain the appropriate ‘valid for driving’ value.
Статуси на картата
Card statuses
Статус на картата
Card Status
ОКИК е получил заявление за издаването на карта на водач.
The CIA has received an application to issue a driver card.
Одобрено
Approved
Индивидуализирана
Personalised
Изпратена
Dispatched
Националният орган е изпратил картата на водач на съответния водач или на предоставящата агенция.
The National Authority has dispatched the driver card to the relevant driver or delivering agency.
Връчена
Handed Over
Конфискувана
Confiscated
Компетентният орган е конфискувал картата на водач от водача.
The driver card has been taken from the driver by the competent authority.
Временно прекратена
Suspended
На водача временно е конфискувана картата на водач.
The driver card has been taken temporarily from the driver.
Отнемане
Withdrawn
ОКИК е решил да отнеме картата на водач.
The CIA has decided to withdraw the driver card.
Картата е обявена за невалидна за постоянно.
The card has been permanently invalidated.
Върната
Surrendered
Тахографската карта е върната на ОКИК и е обявено, че повече не е необходима.
The tachograph card has been returned to the CIA, and declared no longer needed.
Изгубена
Lost
Открадната
Stolen
Неизправна
Malfunctioning
Изтекъл срок
Expired
Срокът на валидност на тахографската карта е изтекъл.
The period of validity of the tachograph card has expired.
Заменена
Replaced
Тахографската карта, която е докладвана за загубена, открадната или неизправна, е заменена с нова.
The tachograph card, which has been reported lost, stolen or malfunctioning, has been replaced by a new card.
Данните върху новата карта са същите, с изключение на това, че индексът за замяна в номера на картата е увеличен с единица.
The data on the new card is the same, with the exception of the card number replacement index, which has been increased by one.
Подновена
Renewed
Номерът на новата карта е същият, с изключение на това, че индексът за замяна в номера на картата е увеличен с единица.
The card number of the new card is the same, with the exception of the card number renewal index, which has been increased by one.
В процес на замяна
In Exchange
ОКИК, който е издал дадена карта на водач, е получил уведомление, че е започнала процедура за замяна на въпросната карта с карта на водач, издадена от ОКИК на друга страна.
The CIA that issued a driver card has received a notification that the procedure to exchange that card for a driver card issued by the CIA of another Party has started.
Заменена
Exchanged
ОКИК, който е издал дадена карта на водач, е получил уведомление, че процедурата за замяна на въпросната карта с карта на водач, издадена от ОКИК на друга страна, е приключила.
The CIA that issued a driver card has received a notification that the procedure to exchange that card for a driver card issued by the CIA of another Party has completed.
Поддопълнение 4.3
Sub-appendix 4.3
Разпоредби относно съобщенията по TACHOnet
Message provisions of TACHOnet
Централният възел трябва да осигурява както синхронен, така и асинхронен интерфейс за обмен на съобщения.
The central hub shall provide both synchronous and asynchronous interfaces for the exchange of messages.
Страните имат възможност да изберат интерфейса с най-подходящата технология за свързване със своите приложения.
Parties may choose the most suitable technology to interface with their own applications.
Всички съобщения, обменяни между централния възел и националните системи, трябва да са кодирани в UTF-8.
All messages exchanged between the central hub and the national systems must be UTF-8 encoded.
Националните системи трябва да могат да получават и обработват съобщения, съдържащи букви от гръцката азбука или кирилица.
National systems shall be capable of receiving and processing messages containing Greek or Cyrillic characters.
Структура и определяне на схемата (XSD) на съобщенията XML
XML messages structure and Schema definition (XSD)
Общата структура на съобщенията XML трябва да е в съответствие с формата, определен от схемите XSD, инсталирани в централния възел.
The general structure of XML messages shall follow the format defined by the XSD schemas installed in the central hub.
Централният възел и националните системи трябва да предават и приемат съобщения, които отговарят на схемата XSD на съобщението.
The central hub and the national systems shall transmit and receive messages that conform to the message XSD schema.
Националните системи трябва да могат да изпращат, получават и обработват всички съобщения, съответстващи на някоя от функционалните възможности, определени в поддопълнение 4.2.
National systems shall be capable of sending, receiving and processing all messages corresponding to any of the functionalities set out in Sub-appendix 4.2.
Съобщенията XML трябва да включват най-малкото минималните изисквания, определени в таблица 2.
The XML messages shall include at least the minimum requirements laid down in Table 2.
Минимални изисквания към съдържанието на XML съобщенията
Minimum requirements for the content of the XML messages
Официалната версия на спецификациите XML ще се посочва посредством мястото за име, определено в XSD на съобщението, както и в атрибута за версията на заглавния елемент на всяко съобщение XML.
The official version of the XML specifications will be specified through the namespace defined in the message XSD and in the version attribute of the Header element of any XML message.
Номерът на версията („n.m“) ще се определя като постоянна стойност във всяка версия на файла за определяне на схемата на XML (xsd).
The version number (‘n.m’) will be defined as fixed value in every release of the XML Schema Definition file (xsd).
Идентификатор при изпитване
Test Identifier
Незадължителен идентификатор при изпитване.
Optional id for testing.
Инициаторът на изпитването попълва идентификатора и всички участници в работния процес препращат/връщат същия идентификатор.
The originator of the test will populate the id and all participants in the workflow will forward/return the same id.
При реална работа той следва да бъде игнориран и не се използва, ако е предоставен.
In production it should be ignored and will not be used if it is supplied.
Технически идентификатор
Technical Identifier
Универсален уникален идентификатор (UUID), който еднозначно определя всяко отделно съобщение.
A UUID uniquely identifying each individual message.
Тези данни не се използват със стопанска цел.
This data is not used in any business capacity.
Идентификатор на работния процес
Workflow Identifier
Идентификаторът на работния процес (workflowId) представлява UUID и следва да бъде генериран от запитващата страна.
The workflow id is a UUID and should be generated by the requesting party.
Този идентификатор се използва след това във всички съобщения с цел взаимовръзка с работния процес.
This id is then used in all messages to correlate the workflow.
Изпратено в
Sent At
Датата и часът (UTC) на изпращане на съобщението.
The date and time (UTC) that the message was sent.
Срок на изтичане
Timeout
Това е незадължителен атрибут за дата и време (във формат UTC).
This is an optional date and time (in UTC format) attribute.
Тази стойност се задава само от централния възел за препратени запитвания.
This value will be set only by the central hub for forwarded requests.
Тя информира отговарящата страна за момента, в който запитването изтича.
This will inform the responding party of the time when the request will be timed out.
Тази стойност не се изисква в MS2TCN__Req и във всички съобщения за отговор.
This value is not required in MS2TCN__Req and all response messages.
Тя не е задължителна, така че за всички видове съобщения може да се използва една и съща заглавна част, независимо от това дали се изисква атрибутът timeoutValue.
It is optional so that the same header definition can be used for all message types regardless of whether or not the timeoutValue attribute is required.
Кодът по ISO 3166-1 Alpha 2 на страната, изпращаща съобщението, или „ЕС“.
The ISO 3166-1 Alpha 2 code of the party sending the message or ‘EU’.
Кодът ISO 3166-1 Alpha 2 на страната, до която се изпраща съобщението, или „ЕС“.
The ISO 3166-1 Alpha 2 code of the party to which the message is being sent or ‘EU’.
Поддопълнение 4.4
Sub-appendix 4.4
Услуги по транслитерация и NYSIIS (Система на щата Ню Йорк за идентификация и информация)
Transliteration and NYSIIS (New York State Identification and Intelligence System) services
При търсене на карта посредством функционалната възможност CIC като основен метод за търсене трябва да се използват ключовете NYSIIS.
When searching for a card via the CIC functionality the NYSIIS keys shall be used as the primary search mechanism.
В допълнение страните могат да използват индивидуализиран алгоритъм с цел намиране на допълнителни резултати.
Additionally, parties may employ a custom algorithm to return additional results.
В резултатите от търсенето трябва да е посочен методът на търсене, който е използван за намирането на даден запис — NYSIIS или индивидуализиран.
The search results shall indicate the search mechanism which was used to find a record, either NYSIIS or custom.
Ако дадена страна реши да записва уведомления ICDL, ключовете NYSIIS, съдържащи се в уведомлението, се записват като част от данните за ICDL.
If a party chooses to record ICDL notifications then the NYSIIS keys contained in the notification shall be recorded as part of the ICDL data.
При търсене на данните за ICDL страната трябва да използва ключовете NYSIIS на името на заявителя.
When searching the ICDL data the party shall use the NYSIIS keys of the applicant's name.
Поддопълнение 4.5
Sub-appendix 4.5
За обмена на съобщения между централния възел и националните системи се използва HTTPS.
HTTPS shall be used for the exchange of messages between the central hub and the national systems.
Националните системи използват цифровите сертификати, посочени в поддопълнения 4.8 и 4.9, за целите на сигурността на предаването на съобщения между националната система и централния възел.
National systems shall use the digital certificates referred to in Sub-appendices 4.8 and 4.9 for the purposes of securing the transmission of messages between the national system and the central hub.
Националните системи използват, като минимум, сертификати с алгоритъм SHA-2 (SHA-256) за хеширане на подписа и публичен ключ с дължина 2048 бита.
National systems shall implement, as a minimum, certificates using the SHA-2 (SHA-256) signature hash algorithm and a 2048 bit public key length.
Поддопълнение 4.6
Sub-appendix 4.6
Нива на обслужване
Service levels
Националните системи трябва да осигуряват следното минимално ниво на обслужване:
National systems shall fulfil the following minimum level of service:
Те трябва да са разполагаеми 24 часа в денонощието, 7 дни в седмицата.
They shall be available 24 hours a day, 7 days a week.
Разполагаемостта им трябва да се следи чрез генерирането от централния възел на периодично съобщение за състоянието.
Their availability shall be monitored by a heartbeat message issued from the central hub.
Степента им на разполагаемост трябва да бъде 98 % в съответствие със следната таблица (стойностите са закръглени до най-близката подходяща единица):
Their availability rate shall be 98 %, according to the following table (the figures have been rounded to the nearest convenient unit):
Разполагаемост от
An availability of
означава неразполагаемост от
means an unavailability of
Дневно
Daily
Месечно
Monthly
Годишно
Yearly
0,5 часа
0,5 hours
15 часа
15 hours
7,5 дни
7,5 days
Страните се насърчават да спазват дневния процент на разполагаемост, но въпреки това се признава, че определени необходими дейности, например поддръжка на системата, изискват прекъсвания в работата за повече от 30 минути.
Parties are encouraged to respect the daily availability rate, however it is recognised that certain necessary activities, such as system maintenance, require a downtime of more than 30 minutes.
Спазването на месечния и годишния процент на разполагаемост обаче е задължително.
However, the monthly and yearly availability rates remain mandatory.
Те трябва да отговарят на най-малко на 98 % от запитванията, изпратени до тях за един календарен месец.
They shall respond to a minimum of 98 % of the requests forwarded to them in one calendar month.