CC BY
0
УДК 004.728.4
DOI: 10.24412/2071-6168-2024-12-255-256
МОДЕЛИРОВАНИЕ ПРОЦЕССОВ ПЕРЕДАЧИ ДАННЫХ В КОМПЬЮТЕРНЫХ СЕТЯХ ДЛЯ ОБЕСПЕЧЕНИЯ ВЗАИМОДЕЙСТВИЯ ИНТЕЛЛЕКТУАЛЬНЫХ АГЕНТОВ
А.В. Ермаков, Л.И. Сучкова, Е.Г. Андреева, А.М. Парамонов, В.Ю. Кобенко
Рассмотрено моделирование обмена данными между интеллектуальными агентами с целью выявления метрик информационно-вычислительных сетей, наиболее полно описывающих их характеристики. Исследованы метрики круговой задержки, величины потерь сетевых пакетов, джиттер между доставкой последовательных сетевых пакетов и пропускная способность сети. Разработано программное обеспечение на языке программирования Rust по активному сбору метрики круговой задержки сети и проведены эксперименты для моделей процессов передачи данных интеллектуальными агентами для различных сетей.
Ключевые слова: информационно-вычислительные сети, метрики оценки качества, сетевой уровень, моделирование, rust.
Промышленные сети широко применяются для автоматизации и управления технологическими процессами и производствами [1-4]. Наличие функционирующей промышленной сети является обязательным условием для непрерывной работы автоматизированных систем управления технологическими процессами (АСУТП) [5]. Построенная на базе промышленного Ethernet промышленная сеть и более известная обычная информационно-вычислительная сеть Ethernet имеют много общего [6], что позволяет сначала выстраивать и проверять гипотезы на обычной компьютерной сети, а потом распространять полученные выводы на промышленные сети.
Компьютерные сети характеризуются рядом величин, значения которых напрямую влияют на производительность и надёжность передачи данных между узлами данной сети. Измеренные значения этих величин представляют собой метрики сети.
Отдельные метрики сети могут быть тесно связаны друг с другом, другие же не оказывать существенного влияния на её производительность и надёжность. В некоторых случаях могут отсутствовать очевидные способы измерения метрики сети, формализации и описания параметров метрики [7].
Исследование скорости и надёжности передачи данных актуально для коллектива интеллектуальных агентов, решающих совместно поставленную задачу. Успешность выполнения задачи коллективом интеллектуальных агентов зависит от надёжности коммуникаций между членами коллектива, а именно от гарантии доставки сообщения до исполнителя и получения ответа.
Целью работы является проведение модельных экспериментов для выявления метрик сетей, наиболее значительно влияющих на надёжность передачи данных в IP-сетях.
Методы моделирования. Для моделирования процессов передачи данных в информационно-вычислительной сети использовался собственный сетевой tun-интерфейс. Данный метод позволил получить полную поддержку маршрутизации пакетов на уровне операционной системы и обеспечил доступ к содержимому сетевых пакетов на третьем (сетевом) уровне модели OSI, а также возможность отправки любых IPv4-пакетов внутрь моделируемой сети и получения пакетов из него.
В качестве задаваемых свойств сети использовались следующие: задержка в передаче пакета в соединении между узлами сети и на узле сети; пропускная способность соединения; величина потерь на узле сети.
На рис. 1 приведена структура моделируемой компьютерной сети. Между двумя узлами сети построен маршрут, по которому передаются данные, приведены задаваемые характеристики соединений между узлами сети: пропускная способность и задержка.
соединение между узла мм сети
Рис. 1. Структура моделируемой информационно-вычислительной сети
255
Измерение метрик. Для разных метрик сети существуют различные методологии измерения, включая следующие [7]:
- непосредственная оценка значения измеряемой величины, например, измерение круговой задержки (round-trip time, RTT) выполняется путём внедрения IP-пакета заданного размера на заданном маршруте сети;
- агрегация измеряемой величины из других величин, например, односторонняя задержка (one way delay, OWD) вычисляется путём агрегирования задержек, возникающих при передаче данных на каждом узле сети, через которые проходит маршрут передачи пакета;
- оценка измеряемой величины на основе косвенно влияющих величин, например, оценка значения односторонней сетевой задержки может быть вычислена путём умножения значения круговой задержки на коэффициент;
- ретроспективное вычисление метрики из других метрик, значения которых известны в предыдущие периоды измерений, например, пропускную способность можно оценить на основе накопленной статистики точных измерений.
Процесс измерения метрики сети может повлиять на измеряемое значение, из этого следует, что следует отдавать предпочтение тем методикам, которые не будут создавать значительную нагрузку на исследуемую сеть, либо по возможности следует постараться ограничиться пассивным наблюдением за передаваемыми данными по сети. При измерении метрик сети также необходимо учитывать наличие инструментальных погрешностей метода измерения и постараться как можно точнее оценить их влияние. Производные метрики, полученные из других метрик, имеют меньшую ценность, чем метрики, полученные непосредственно путём измерений.
Моделирование круговой задержки. Круговая задержка является временем, которое потребуется, чтобы пакет с данными был доставлен от одного узла сети к другому (так называемая односторонняя задержка), плюс время на доставку обратного пакета — подтверждения доставки.
Для моделирования круговой задержки на каждом участке построенного маршрута задавалась её плотность вероятности, имеющая логарифмически-нормальное распределение случайной величины. Используемое распределение является двухпараметрическим, то есть зависит от математического ожидания и дисперсии, что упрощает моделирование и уменьшает количество суммарных параметров в модели информационно-вычислительной сети. Параметры распределения случайной величины задержки задаются в миллисекундах.
Итоговая круговая задержка вычисляется как агрегация всех задержек на маршруте сети. На рис. 2 показана взаимосвязь между круговой задержкой (RTT), односторонней задержкой (OWD) и задержками на каждом узле моделируемой сети (t1, t2, t3, t4, t5, t6).
Метрика круговой задержки определялась в миллисекундах.
node 1 node 2 node 3 node 4
на каждом узле сети (t1, t2, t3, t4, t5, t6)
Измерение круговой задержки. Односторонняя задержка является сложноизмеримой, как минимум, она требует синхронизации часов реального времени с большой точностью (доли миллисекунд) на обоих узлах сети, между которыми проводится замер этой метрики [7]. На практике одностороннюю задержку пытаются оценить путём деления RTT, что сводит на нет полезность метрики.
Выделяют два способа измерения данной метрики в зависимости от активного вмешательства в сеть, либо простого пассивного наблюдения за передаваемыми пакетами в сети:
- отправка собственных пакетов через сеть. Каждый пакет помечается уникальным числом-идентификатором, сохраняется точное время отправки. Удалённый узел принимает пакет, безусловно пересылает его отправителю с сохранением уникального идентификатора. Разность между отправкой и получением обратно пакета с этим же идентификатором и будет искомой величиной круговой задержки;
- глубокая инспекция пакетов (deep packet inspection, DPI), передаваемых по сети, с целью получения уникальных идентификаторов и вычисления круговой задержки.
Протокол межсетевых управляющих сообщений (internet control message protocol, ICMP) описан в стандарте интернета RFC 792 [8] и является протоколом третьего (сетевого) уровня по сетевой модели OSI. В частности, стандарт определяет ICMP-сообщения с типом 8 (эхо-запрос) и 0 (эхо-ответ). Вышеперечисленные типы ICMP-сообщений используются в широко известной и применяемой прикладной утилите ping, которая служит для проверки возможности доставки IP-пакетов удалённым узлом сети.
При моделировании один узел сети отправляет ICMP-пакеты с типом «эхо-запрос», а узел сети — получатель отвечает на запрос ICMP-пакетом с типом «эхо-ответ». Использование стандартного сетевого протокола упрощает проектирование программного обеспечения по сбору метрик сети, а также упрощает проведение самих измерений метрик, так как программное обеспечение требуется разворачивать только на одном из контролируемых нами узлов сети, а не всех, представляющих интерес исследования. Развёртывать разработанное программное обеспечение и запускать с повышенными привилегиями администратора операционной системы с целью низкоуровневой работы с так называемыми сырыми сокетами (raw socket) может быть затруднительно, а то и вовсе невозможно. Например, по причине наличия защиты от модификаций и вмешательства в прошивку промышленного оборудования, подключённого к промышленной сети.
Моделирование потерь сетевых пакетов. Потери сетевых пакетов в промышленных сетях являются серьёзной проблемой, поэтому целесообразно отслеживать данную метрику при моделировании. Конечно, существуют способы повышения стабильности, надёжности и доступности сетевых соединений, например, протокол резервирования PRP (Parallel Redundancy Protocol) [9-10], однако они применяются не для всех промышленных сетей.
При моделировании примем, что передаваемый по сети пакет данных будет теряться с вероятностью, подчиняющемуся равномерному распределению.
Измерение величины потерь сетевых пакетов. При оценке метрики величины потерь сетевых пакетов возникает естественное желание выразить метрику в виде вероятности потери конкретного пакета. Но если выражать метрику в терминах теории вероятности, то в определении метрики будут лежать скрытые предположения о стохастической модели поведения. Следует избегать выражения метрик в виде вероятности, чтобы избежать искажения характеристик моделируемой промышленной сети.
Поэтому метрику величины потерь определим как отношение числа потерянных пакетов к общему числу отправленных. Например, 3 потерянных пакета из 100 отправленных означает, что метрика равна 0,03.
Моделирование джиттера. В сетевых протоколах чаще всего важен порядок посылаемых и принимаемых пакетов [11-12]. Если джиттер — разница в задержках между доставкой последовательных пакетов — значительно превышает средний показатель задержки, то порядок доставленных пакетов может быть нарушен (рис. 3). На принимающей стороне, как правило, есть небольшой буфер, в который помещаются последовательно поступающие пакеты, и для восстановления порядка потребуется дополнительное время, чтобы дождаться, когда придёт предыдущий пакет. Некоторые вышележащие сетевые протоколы, такие как TCP, чувствительны к джиттеру, поэтому мы добавляем эту характеристику сети в отслеживаемую метрику.
При моделировании джиттер возникает естественным образом, как было сказано выше, при значительно возросшей задержке отдельного пакета по сравнению со средней задержкой остальных пакетов.
Метрику джиттера определим в миллисекундах.
Измерение джиттера. Величина джиттера вычисляется как разница между усреднённым значением круговой задержки и максимальным значением круговой задержки за рассматриваемый промежуток времени.
node 1 node 2
I I
сети при значительном джиттере
Моделирование пропускной способности. Промышленные сети имеют значительные отличия от информационно-вычислительных сетей общего назначения в контексте пропускной способности и используемой ширины канала [13]. В то время как информационно-вычислительные сети передают так называемый пульсирующий трафик, и внутри канала передачи данных могут возникать временные перегрузки и 100 %-я утилизация канала связи, то в промышленных сетях подобное поведение недопустимо, так как перегруженные каналы связи приводят к неизбежному возрастанию метрик круговой задержки, джиттера и потери пакетов.
Для моделирования пропускной способности использовался алгоритм дырявого ведра (leaking bucket).
Описание разработанного программного обеспечения. Для проведения экспериментальных замеров метрик и моделирования процессов передачи данным между интеллектуальными агентами было разработано программное обеспечение, зарегистрированное в Реестре программ для ЭВМ [14].
Разработанное программное обеспечение написано с использованием языка программирования Rust и реализует консольный интерфейс пользователя (command line interface, CLI), несколько уровней журналирования работы, устанавливаемый через CLI, и основной функционал отправки и принятия пакетов с замером круговой задержки. Замеры в процессе работы программного обеспечения сохраняются в текстовый формат файла CSV (comma-separated values, значения, разделённые запятыми) для дальнейшей статистической обработки.
По данным компаний Microsoft и Google, около 70 % уязвимостей вызваны небезопасной работой с памятью [15-16]. Предполагается, что использование языка Rust для разработки позволит снизить риск появления уязвимостей, вызванных небезопасной работой с памятью.
При разработке программного обеспечения основой является формализация структуры используемых данных. Ниже приведена реализация перечисления на языке программирования Rust, которая описывает ICMP-сообщения с типом 8 (эхо-запрос) и 0 (эхо-ответ).
Описание перечисления типов ICMP-сообщений имеет вид: /// Тип ICMP-пакета
#[derive(Debug, PartialEq, Copy, Clone, Default, TryFromPrimitive)] #[repr(u8)] pub enum Type { /// Эхо-ответ EchoReply = 0, /// Эхо-запрос #[default] EchoRequest = 8,
}
static_assert_size !(Type, 1);
С помощью атрибута #[derive] компилятор способен предоставить основные реализации для некоторых типажей, а именно: Debug для отладочного вывода; PartialEq для возможности сравнения двух объектов; Copy и Clone для копирования объектов, Default позволяет создавать объекты перечисления с поведением по умолчанию, атрибут #[default] задаёт тип 8 (эхо-запрос); TryFromPrimitive предоставляет сторонняя библиотека num_enum, реализация десериализации из примитивного типа данных u8, беззнакового целого восьмибитного числа.
Атрибутом #[repr(u8)] задаётся внутреннее представление перечисления, в данном случае перечисление имеет всего два варианта, и оба варианта представлены положительными числами и меньше значения 255, что позволяет использовать тип данных u8.
Статический макрос static_assert_size проверяет во время компиляции утверждение и перепроверяет фактический размер перечисления, которое равно одному байту.
Описание структуры ICMP-сообщений имеет вид: /// ICMP-пакет
#[derive(Debug, PartialEq, Default, bincode::Encode, bincode::Decode)] pub struct Icmp { /// Тип
pub typ: Type,
/// Код
pub code: u8,
/// Контрольная сумма
pub checksum: u16,
/// Идентификатор
pub id: u16,
/// Номер последовательности pub seq: u16,
}
static_assert_size!(Icmp, 8);
Порядок полей и типы данных структуры описаны в стандарте интернета RFC 792 [8], выше приведена реализация на языке программирования Rust. Автоматически реализованы типажи сторонней библиотеки bincode, а именно bincode::Encode, bincode::Decode (для кодирования ICMP-сообщений и декодирования из байтов соответственно). Статический макрос static_assert_size проверяет фактический размер структуры на момент компиляции, как сделано аналогично для перечисления Type. Стоит отметить, что в текущей реализации структуры ICMP-сообщения отсутствует поле с полезной нагрузкой.
Десериализация ICMP-пакета в описанную ранее программную структуру имеет вид: impl TryFrom<&[u8]> for Icmp { type Error = bincode::error::DecodeError; fn try_from(value: &[u8]) -> Result<Self, Self::Error> { let config = get_config_bincode();
let (result, size) = bincode::decode_from_slice(value, config)?;
debug_assert_eq!(size, size_of: :<Self>());
Ok(result)
}
}
Вручную реализован типаж TryFrom для байтового среза данных. Типаж позволяет провести десериали-зацию структуры во всеми вложенными полями из байтового среза данных. Если десериализация окажется неудачной, то вместо сконструированного объекта структуры функция try_from вернёт ошибку, описанную в типе данных
Self::Error.
При вызове функция try_from принимает одним параметром срез байтовых данных, размер которых неизвестен на момент компиляции, дальше получает конфигурацию, общую для всего приложения и необходимую для проведения десериализации с использованием библиотеки bincode. Оператор «?» является синтаксическим сахаром, в случае ошибки выполнение функции завершается, и функция возвращает инвариант с типом Err(bincode::error::DecodeError), то есть ошибку. Если декодирование из среза данных прошло успешно, то конструируется объект структуры (переменная result) и в переменной size содержится количество байт, сколько было вычитано из среза данных при конструировании структуры. При компиляции в режиме отладки макрос debug_assert_eq дополнительно проверяет на равенство количество вычитанных байт и фактический размер структуры. В режиме релиза данный макрос в исполняемом коде не содержится. И последняя строка Ok(result) возвращает инвариант перечисления Result.
С использованием написанного программного обеспечения были осуществлены замеры метрик четырёх моделируемых сетей:
- проводной Ethernet 100 Мбит/с на промышленных коммутаторах;
- проводной Ethernet 1000 Мбит/с на SOHO-маршрутизаторе (small office/home office, для домашних сетей и малых офисных сетей);
- беспроводной Wi-Fi на SOHO-маршрутизаторе;
- беспроводная мобильная сеть 4G.
Результаты измерений круговой задержки (RTT) для четырёх сетей приведены в таблице.
Стандартные статистики RTT для моделируемых сетей
Статистика eth100 eth1000-soho wi-fi 4g
Минимум (мс.) 0,104 0,122 0,843 55,933
Максимум (мс.) 2,360 20,323 312,347 235,187
Размах (мс.) 2,256 20,201 311,513 179,254
Матожидание (мс.) 0,136 0,189 2,726 58,603
Стандартное отклонение (мс.) 0,040 0,431 12,150 21,617
На рис. 4 приведены результаты измерений круговой задержки для четырёх моделируемых сетей. Всего проводилось 30 000 последовательных замеров. Размах значений для проводных сетей и беспроводной мобильной сети 4G относительно небольшой, тогда как для беспроводной сети Wi-Fi присутствуют выбросы, на несколько порядков превышающие математическое ожидание величины.
ethlOO ethl000-soho wi-fi
40
10;
10J
Ё
Ё ю1
10°
ethlOOO-soho
4д
Рис. 4. Результаты измерений RTT для четырёх моделируемых сетей: eth100 — проводной Ethernet 100 Мбит/с на промышленных коммутаторах; eth1000-soho — проводной Ethernet 1000 Мбит/с на SOHO-маршрутизаторе; wi-fi — беспроводной Wi-Fi на SOHO-маршрутизаторе; 4g — беспроводная
мобильная сеть 4G
Визуализация выборки (рис. 5) показывает более точное распределение значений круговой задержки в моделируемых сетях. Если для проводной компьютерной сети Ethernet 100 Мбит/с на промышленных коммутаторах выбросы минимальные и не достигают величины 2,5 мс., то аналогичная компьютерная сеть на SOHO-маршрутизаторе показывает нестабильность параметра круговой задержки и редкие выбросы на 20 мс., которые приводят к возникновению джиттера передаваемых пакетов.
Б
* ■
Ш:
10 о ethlOOO-soho
%
4+Ц #
10.0 wi-fl
Л
*■ ++ ++ . +++.
++ ■ 1
++
200 4g
■ ++
50
100
150
250
300
350
200 КГПпги)
Рис. 5. Результаты измерений ЛТТ для четырёх моделируемых сетей, случайная выборка значений,
одна точка — одно значение
Из-за несовершенства генератора псевдослучайных чисел, использовавшемся при моделировании сетей в полученных результатах замеров круговой задержки компьютерных сетей на SOHO-маршрутизаторе и беспроводной сети Wi-Fi присутствуют области повышенной вероятности значений, что видно на рис. 5 в виде скоплений точек в одной области (диапазон около 1 мс. для eth1000-soho и диапазон 150-300 мс. для wi-fi).
Для беспроводной мобильной сети 4G измеренное распределение наиболее стабильное и лучше остальных подчиняется логарифмически-нормальному закону распределения случайной величины.
Выводы. Исследованы метрики круговой задержки, величины потерь сетевых пакетов, джиттер доставки пакетов и пропускная способность сети. Разработано программное обеспечение на языке программирования Rust по активному сбору метрики круговой задержки сети. Проведены модельные эксперименты обмена данными между интеллектуальными агентами для различных сетей, позволяющие разработчикам интеллектуальных агентов принимать решения о выборе программно-аппаратной платформы при проектировании компьютерной сети.
Список литературы
1. Майорова К.С., Балашова Е.С. Цифровой переход промышленных предприятий в «smart» экосистему // Экономика промышленности / Russian Journal of Industrial Economics. - 2021. - Т. 14. - № 4. - С. 433-444. DOI: 10.17073/2072-1633-2021 -4-433-444
2. Гайкович Г.Ф. Стандартизация в области промышленных сетей. Развитие беспроводных стандартов для АСУ ТП // Электронные компоненты. - 2009. - № 1. - С. 48-52.
3. Ястреб Н.А. Четвёртая промышленная революция: глобальные промышленные сети и Интернет вещей // Инновационный вестник регион. - Воронеж, 2014. - № 4. - С. 22-26.
4. Кобенко В.Ю. Компьютерные технологии в науке и производстве: учебное пособие. / В.Ю. Кобенко, Ю.Н. Кликушин. - Омск: Изд-во ОмГТУ, 2010. - 103 с. - ISBN 978-5-8149-0838-4
5. Sen S.K. Fieldbus and networking in process automation. - CRC Press, 2021. DOI: 10.1201/9781003149941
6. Орлов С. Ethernet и промышленные сети // Журнал сетевых решений LAN. - 2013. - № 9. - С. 24-31.
7. RFC 2330: Framework for IP Performance Metrics, 1998. [Электронный ресурс] URL: https://datatracker.ietf.org/doc/html/rfc2330 (дата обращения: 10.05.2024).
8. RFC 792: Internet Control Message Protocol, 1981. [Электронный ресурс] URL: https://datatracker. ietf. org/doc/html/rfc792 (дата обращения: 10.05.2024).
9. Дормаков М. Повышение надёжности беспроводных промышленных сетей с помощью протокола PRP // Современные технологии автоматизации. - 2015. - № 1. - С. 8-11.
10. Oleiwi S.S., Mohammed G.N. Mitigation of packet loss with end-to-end delay in wireless body area network applications // International journal of electrical and computer engineering. - 2022. - Т. 12. - № 1. - С. 460.
11. Beech S. et al. How changes in the mean latency, jitter amplitude, and jitter frequency impact target acquisition performance // ACM Transactions on Applied Perception. - 2024. DOI: 10.1145/3701984
12. Angrisani L. et al. Packet jitter measurement in communication networks: A sensitivity analysis // 2011 IEEE international workshop on measurements and networking proceedings (M&N). - IEEE, 2011. - С. 146-151.
13. Лопухов И. Резервирование промышленных сетей Ethernet на втором уровне OSI: стандарты и технологии // Современные технологии автоматизации. - 2009. - № 3. - С. 16-32.
14. Свидетельство о государственной регистрации программы для ЭВМ № 2024618323. TwilightNet: оценка параметра круговой задержки при обмене данными в информационно-вычислительных сетях / А.В. Ермаков. - Заявка № 2024617176. Дата поступления 04 апреля 2024 г. Зарегистрировано в Реестре программ для ЭВМ 10 апреля 2024 г.
15. Matt Miller. Trends and Challenges in the Vulnerability Mitigation Landscape // USENIX Association, 2019
16. Memory safety / The Chromium Projects. [Электронный ресурс] URL: https://www.chromium.org/Home/chromium-security/memory-safety (дата обращения: 10.05.2024).
Ермаков Александр Васильевич, сотрудник, [email protected], Россия, Барнаул, Алтайский государственный технический университет им. И.И. Ползунова,
Сучкова Лариса Иннокентьевна, д-р техн. наук, профессор, [email protected], Россия, Барнаул, Алтайский государственный технический университет им. И.И. Ползунова,
Андреева Елена Григорьевна, д-р техн. наук, профессор, lenandr02@yandex. ru, Россия, Омск, Омский государственный технический университет,
Парамонов Александр Михайлович, д-р техн. наук, профессор, [email protected], Россия, Омск, Омский государственный технический университет,
Кобенко Вадим Юрьевич, д-р техн. наук, профессор, kobra_vad@rambler. ru, Россия, Омск, Омский государственный технический университет
MODELING OF DATA TRANSFER PROCESSES OF INTELLIGENT AGENTS IN COMPUTER NETWORKS A.V. Ermakov, L.I. Suchkova, E.G. Andreeva, A.M. Paramonov, V.Yu. Kobenko
The article considers modeling of data exchange between intelligent agents to identify metrics of computer networks that mostfully describe their characteristics. The metrics of round-trip delay, the values of network packet losses, jitter between the delivery of successive network packets and network throughput are used. Software is developed in the Rust programming language for collecting the metrics of round-trip delay of the network and experiments are conducted for models of data transmission processes by intelligent agents for various networks.
Key words: computer network, quality assessment metrics, network level, modeling, rust.
Ermakov Alexandr Vasilevich, employee, [email protected], Russia, Barnaul, Altai State Technical University,
Suchkova Larisa Innokentevna, doctor of technical sciences, professor, edu.digit@altgtu. ru, Russia, Barnaul, Altai State Technical University,
Andreeva Elena Grigorevna, doctor of technical sciences, professor, lenandr02@yandex. ru, Russia, Omsk, Omsk State Technical University,
Paramonov Alexandr Mihajlovich, doctor of technical sciences, professor, amparamonov@mail. ru, Russia, Omsk, Omsk State Technical University,
Kobenko Vadim Yurevich, doctor of technical sciences, professor, kobra [email protected], Russia, Omsk, Omsk State Technical University
УДК 004.91
Б01: 10.24412/2071-6168-2024-12-261 -262
АВТОМАТИЗАЦИЯ УЧЕТА ТРУДА И ЗАРАБОТНОЙ ПЛАТЫ НА МАЛОМ ПРЕДПРИЯТИИ
Т.В. Гладких, Л.А. Коробова
Статья посвящена автоматизация учета труда и заработной платы на малом предприятии с целью повышение эффективности управления персоналом, сокращение временных и финансовых затрат на учет и расчеты, а также минимизация риска возникновения ошибок в учете труда и заработной платы.
Ключевые слова: автоматизация учета труда, заработная плата, бизнес-процессы, временные затраты, информационная система.
По мере развития компании и увеличения числа ее сотрудников возникает потребность в эффективной обработке растущих объемов информации. Особенно актуальна эта проблема для компаний, занимающихся торговлей и оказанием различного вида услуг, что связано с обработкой большого количества финансовых транзакций и формированием множества бухгалтерских и отчетных документов.
Основной целью разработки информационной системы (ИС) является повышение эффективности функционирования компании и управление персоналом. При этом критериями оценки являются сокращение временных и финансовых затрат на учет и экономические расчеты, а также минимизация риска возникновения ошибок в учете труда и заработной платы.
Разрабатываемая ИС должна поддерживать следующие функциональные требования[1].
1. Ведение базы сотрудников и поддержания её в актуальном состоянии.
2. Расчёт заработной платы сотрудников предприятия. Заработная плата вначале рассчитывается в зависимости от оклада сотрудника, а затем корректируется в зависимости от полученных премий и штрафов, в результате чего формируется окончательная сумма.
