Русские Блоги
text, data и bss: подробное объяснение пространства, занимаемого кодом и данными
Перевод с: https://my.oschina.net/betayuan/blog/1615785
Оригинальная статья: https://mcuoneclipse.com/2013/04/14/text-data-and-bss-code-and-data-size-explained/
In “Code Size Information with gcc for ARM/Kinetis” I use an option in the ARM gcc tool chain for Eclipse to show me the code size:
В статье «Использование компилятора GCC для вывода информации о коде в проектах ARM / Kinetis» я использовал опцию ARM gcc toolchain для Eclipse для вывода и отображения размера кода:
text data bss dec hex filename 0x1408 0x18 0x81c 7228 1c3c size.elf
I have been asked by a reader of this blog what these item numbers really mean. Especially: what the heck is ‘bss’.
Читатель спросил меня в этом блоге, что на самом деле означают значения этих полей, особенно поля ‘bss’.
Note: I’m using the ARM GNU ‘printsize’ utility for gcc, with an example for Kinetis-L (KL25Z).
Примечание. Инструментом, который я использую для вывода информации о пространстве кода, является ARM GNU ‘printsize’, и в качестве примера я использую Kinetis-L (KL25Z).
text
‘text’ is what ends up in FLASH memory. I can show this with adding
Текстовый сегмент наконец сохраняется во флэш-памяти. Добавив следующий код в программу:
void foo(void) < /* dummy function to show how this adds to ‘text’ */ >
Тогда размер сегмента текста увеличивается следующим образом:
to my program, the ‘text’ part increases so:
text data bss 0x1414 0x18 0x81c
Likewise, my new function ‘foo’ gets added to the .text segment, as I can see in the map file generated by the linker:
Аналогично, в файле карты, сгенерированном компоновщиком, я вижу свою недавно добавленную функцию foo, добавленную в текстовый раздел.
*(.text*) .text.foo 0x000008c8 0x8 ./Sources/main_c.o 0x000008c8 foo
But it does not only contain functions, it has constant data as too. If I have a constant table like
Но текстовый раздел содержит не только функции, но и константы. Например, у меня есть постоянная таблица следующим образом:
const int table[] = 5,0,1,5,6,7,9,10>;
Another thing which is included in ‘text’ is the interrupt vector table (more on this later).then this adds to ‘text’ too. That variable ‘table’ will be in FLASH, initialized with the values specified in the source.
Еще одна вещь, включенная в текстовый раздел, — это таблица векторов прерываний (подробно позже), поэтому она также рассчитывается в текстовом разделе. Таблица переменных также будет помещена во FLASH и инициализирована с данными в исходном коде.
In summary: ‘text’ is what ends up typically in FLASH and has code and constant data.
Сводка: текстовый сегмент наконец сохраняется во FLASH, а содержимое содержит код и константы.
data
‘data’ is used for initialized data. This is best explained with the following (global/extern) variable:
Раздел данных используется для инициализации данных. Следующие переменные (глобальные / внешние) могут быть объяснены очень четко:
int32_t myVar = 0x12345678;
Adding above variable to my application will increase the ‘data’ portion by 4 bytes:
Добавление указанных выше переменных приведет к увеличению части данных моего приложения на четыре байта:
text data bss 0x1414 0x1c 0x81c
This variable ‘myVar’ is not constant, so it will end up in RAM. But the initialization (0x12345678) *is* constant, and can live in FLASH memory. The initialization of the variable is done during the normal ANSI startup code. The code will assign/copy the initialization value.
This is sometimes named ‘copy-down’. For the startup code used by CodeWarrior for MCU10.3 for Kinetis-L (ARM Cortex-M0+), this is performed in __copy_rom_sections_to_ram() :
Переменная myVar не является константой, поэтому она в конечном итоге будет храниться в оперативной памяти. Но начальное значение (0x12345678) является константой, поэтому его можно поместить во FLASH. Инициализация этой переменной выполняется в обычном коде запуска ANSI. Иногда это называется «копировать как есть». Для кода запуска, используемого в MCU10.3 версии CodeWarrior для Kinetics-L (ARM Cortex-M0 +), эта операция __copy_rom_sections_to_ram ().
ARM Startup Code Initializing Variables
Инициализация переменных в коде запуска ARM
Just one thing to consider: my variable ‘myVar’ will use space in RAM (4 bytes in my case), *plus* space in FLASH/ROM for the initialization value (0x12345678). So I need to count the ‘data’ size twice: that size will end up in RAM, plus will occupy FLASH/ROM. That amount of data in FLASH is *not* counted in the text portion.
Следует учитывать еще одну вещь: переменная myVar будет занимать пространство ОЗУ (в данном примере 4 байта), а пространство, занимаемое начальным значением (0x12345678) во FLASH / ROM, должно быть накоплено. Поэтому мне нужно рассчитать размер сегмента данных дважды: объем оперативной памяти плюс объем FLASH / ROM. И часть FLASH не включена в текстовую часть.
The ‘data’ only has the initialization data (in my example 0x12345678. And not the variable (myVar).
Раздел данных содержит только данные, используемые для инициализации (0x12345678 в этом примере) и не содержит переменных (myVar).
bss
The ‘bss’ contains all the uninitalized data.
Сегмент bss содержит все неинициализированные данные.
bss (or .bss, or BSS) is the abbreviation for ‘Block Started by Symbol’ by an old assembler (see this link).
bss (.bss, BSS) — это сокращение от «Block Started by Symbol» в старом ассемблере (подробности см. вlink)。
This is best explained with following (global/extern) variable:
Следующие переменные (глобальные / внешние) могут быть объяснены очень четко:
int32_t myGlobal;
Adding this variable will increase the ‘bss’ portion by 4:
Добавление указанных выше переменных приведет к увеличению части bss на 4 байта:
text data bss 0x1414 0x18 0x820
I like to remember ‘bss’ as ‘Better Save Space’ :-). As bss ends up in RAM, and RAM is very valuable for a microcontroller, I want to keep the amount of variables which end up in the .bss at the absolute minimum.
Мне нравится думать о bss как об аббревиатуре «Better Save Space». Поскольку bss наконец хранится в ОЗУ, а ОЗУ является ценным ресурсом для микроконтроллеров, я сделаю так, чтобы количество переменных, хранящихся в bss, было как можно меньше.
The bss segment is initialized in the startup code by the zero_fill_bss() function:
В коде запуска вызовите функцию zero_fill_bss () для инициализации сегмента bss:
static void zero_fill_bss(void) < extern char __START_BSS[]; extern char __END_BSS[]; memset(__START_BSS, 0, (__END_BSS — __START_BSS)); >
dec
The ‘dec’ (as a decimal number) is the sum of text, data and bss:
Dec (сокращение от decimal, то есть десятичное число) — это арифметическая сумма текста, данных и bss.
dec = text + data + bss
Size – GNU Utility
The size (or printsize) GNU utility has more options:
Размер инструмента GNU (printsize) имеет много опций:
size [-A|-B|—format=compatibility] [—help] [-d|-o|-x|—radix=number] [—common] [-t|—totals] [—target=bfdname] [-V|—version] [objfile. ]
The ‘System V’ option can be set directly in the Eclipse panel:
Параметр «System V» может быть установлен непосредственно в Eclipse:

GNU Print Size Option in CodeWarrior for MCU10.3
Опциональный интерфейс GNU Print Size в CodeWarrior MCU версии 10.3
It produces similar information as shown above, but with greater detail.
Это выведет информацию о размере кода, аналогичную приведенной выше, но более подробно.
To illustrate this, I use
Чтобы объяснить это, я использую следующую переменную массива в качестве примера:
int table[] = 1,2,3,4,5>;
While in ‘Berkeley’ mode I get:
Когда выбран режим «Беркли», вывод будет следующим:
text data bss dec hex filename 0x140c 0x2c 0x81c 7252 1c54 size.elf
Выход выбирается следующим образом, когда выбран режим «System V»:
section size addr .interrupts 0xc0 0x0 .text 0x134c 0x800 .data 0x14 0x1ffff000 .bss 0x1c 0x1ffff014 .romp 0x18 0x1ffff030 ._user_heap_stack 0x800 0x1ffff048 .ARM.attributes 0x31 0x0 .debug_info 0x2293 0x0 .debug_abbrev 0xe66 0x0 .debug_loc 0x27df 0x0 .debug_aranges 0x318 0x0 .debug_macinfo 0x53bf3 0x0 .debug_line 0x1866 0x0 .debug_str 0xc23 0x0 .comment 0x79 0x0 .debug_frame 0x594 0x0 Total 0x5defe
I’m using an ARM Cortex-M0+ in my example, so addresses greater 0x1ffff000 are in RAM.
В примере я использовал ядро ARM Cortex-M0 +, поэтому адрес в ОЗУ начинается с 0x1ffff000.
The lines from .ARM.attributes up to .debug_frame are not ending up in the target, they are debug and other information.
среди них.ARM.attributesВплоть до.debug_frameПеречисленный контент не будет размещен на целевом оборудовании, отладке или другой информации.
.interrupts is my interrupt vector table, and .text is my code plus constants, and is in FLASH memory. That makes the 0xc0+0x134c=0x140c for text in ‘Berkeley’.
.interruptsЭто таблица векторов прерываний этого примера, а .text — это код и константы, хранящиеся во FLASH. Поэтому размер текстового раздела в разделе «Беркли» составляет: 0xc0 + 0x134c = 0x140c.
.bss is my uninitialized (zero-outed) variable area. Additionally there is .user_heap_stack: this is the heap defined in the ANSI library for malloc() calls. That makes the total of 0x1c+0x800=0x81c shown in ‘Berkeley’ format.
.bss — неинициализированная (0) область переменных в этом примере. Также есть.user_heap_stack: Сегмент используется для резервирования памяти, выделенной вызовом malloc () в библиотеке ANSI. Таким образом, размер сегмента bss в «Беркли» составляет: 0x1c + 0x800 = 0x81c.
.data is for my initialized ‘table[]’ variable in RAM (5*4 bytes=0x14)
.data хранит инициализированные переменные таблицы [], хранящиеся в RAM в этом примере.
The .romp is used by the linker for the ‘copy-down’ and initialization of .data. But it looks confusing: it is shown with addresses in RAM? Checking the linker map file shows:
romp — это данные инициализации, используемые компоновщиком в данных, которые необходимо «копировать». Но это кажется немного запутанным: адрес, показанный здесь, адрес ОЗУ? Файл карты, созданный компоновщиком, говорит так:
.romp 0x1ffff030 0x18 load address 0x00001b60 0x00001b60 __S_romp = _romp_at 0x1ffff030 0x4 LONG 0x1b4c ___ROM_AT 0x1ffff034 0x4 LONG 0x1ffff000 _sdata 0x1ffff038 0x4 LONG 0x14 ___data_size 0x1ffff03c 0x4 LONG 0x0 0x1ffff040 0x4 LONG 0x0 0x1ffff044 0x4 LONG 0x0
Ah! That actually is not in RAM, but in FLASH: the linker maps this to the FLASH address 0x1b60! So this size 0x18 really needs to be added to the FLASH size too!
какие! На самом деле это не в RAM, а во FLASH: компоновщик сопоставляет этот раздел с адресом FLASH 0x1b60! Следовательно, размер 0x18 нужно добавить к месту, занимаемому FLASH!
Summary
I hope I have sorted out things in a correct way. The way how the initialized data is reported might be confusing. But with the right knowledge (and .map file in mind), things get much clearer:
Надеюсь, я все исправил. Хотя информация в отчете о исходных данных может быть интересной, благодаря правильному анализу (файл .mao в вашей голове) все становится понятнее.
‘text’ is my code, vector table plus constants.
Текст — это код, векторная таблица и константы.
‘data’ is for initialized variables, and it counts for RAM and FLASH. The linker allocates the data in FLASH which then is copied from ROM to RAM in the startup code.
Данные помещают инициализированные переменные и подсчитывают их в RAM и FLASH одновременно. Компоновщик распределяет данные во FLASH, а затем копирует их из ПЗУ в ОЗУ в коде запуска.
‘bss’ is for the uninitialized data in RAM which is initialized with zero in the startup code.
bss помещает неинициализированные переменные в RAM, эти переменные будут заполнены 0 в коде запуска.
Источник: russianblogs.com
OSS/BSS – базовое программное обеспечение в телекоме

OSS/BSS – это аббревиатура от английского Operation Support System/Business Support System. В переводе на русский — система поддержки операций/система поддержки бизнеса. Это класс программных продуктов, которые используют операторы связи, TV-компании, энергетические предприятия и другие организации, регулярно и персонально взаимодействующие с клиентами: ведут индивидуальные аккаунты, следят за потреблением услуг и регулярно выставляют счета своим абонентам. Телекоммуникационная компания не может существовать без процессов, которые обеспечивает OSS/BSS, это ядро ее бизнеса.
Решения класса OSS/BSS отвечают за две стороны работы телекоммуникационной компании: управление инфраструктурой и ресурсами, а также взаимодействие с абонентами. То есть основная функция таких решений, работающих в комплексе, заключается в том, чтобы услуги предоставлялись и учитывались. Эта задача функционально делится на несколько частей. За правильную работу сетевой инфраструктуры и оборудования (сети, подсети, коммутаторы, АТС, базовые станции и т.д.) отвечает OSS.
Взаимодействие с абонентами (учет предоставленных услуг по тарифам, контроль состояния счета, выставление счетов и т.д.) происходит во второй части системы – BSS. Основа BSS – биллинговая система, в которой происходят все финансовые взаиморасчеты с абонентами. Также в этот комплекс может входить система CRM (Customer Relationship Management), отвечающая за отношения с клиентами, в которой хранятся различные данные по каждому абоненту, используемые для маркетинговых целей. Также, в разряд BSS может входить система ERP (Enterprise Resource Planning), которая используется для управления ресурсами предприятия, ведения бухгалтерии, финансового учета, управления проектами, организационной структурой и т.д.
Как видно, эти две стороны деятельности телекоммуникационной компании строятся на различных бизнес-процессах, для обеспечения каждого из которых может использоваться отдельный программный продукт от отдельного вендора. В этом случае неизбежно возникают сложности с интеграцией. Данные из одной программы должны быстро и без потерь передаваться в другую.
Но если инструменты выпущены разными производителями, это становится сложно организовать. Возникает необходимость в доработке и оптимизации систем, на что требуются деньги и время.
Поддержка такого «зоопарка» (именно так это нагромождение называют профессионалы) требует титанических усилий – при обновлении версий программных продуктов возникнуть очередные непредвиденные сложности. Развитие бизнеса требует развития информационной системы, но часто это решается лишь созданием «заплатки» — добавлением очередного программного продукта. Так проблемы накапливаются, как снежный ком, держат в постоянном напряжении ИТ-департамент, и увеличивают финансовые затраты на управление этими «авгиевыми конюшнями». Гораздо более простой и оптимальный путь – использовать полный комплекс программных продуктов OSS/BSS от одного вендора, который уже позаботился о том, чтобы отдельные модули взаимодействовали максимально эффективно и быстро.
Исторически архитектура информационных систем телекоммуникационных компаний развивалась именно по этому пути – от набора самописных собственных решений, которые со значительными усилиями и не до конца интегрированы с готовыми лицензионными продуктами, к использованию комплексных моновендорных систем OSSBSS. Продукты этого класса стали активно распространяться около десяти лет назад. Довольно долгое время, вплоть до 2006-2007 годов, основным средством автоматизации бизнеса у операторов были биллинговые системы.
На практике сегодня в реальных информационных системах можно видеть промежуточный вариант – нечто среднее между описанными выше «зоопарком» и «идеалом». По оценкам J’son Partners, в прошлом году российский рынок систем класса OSS/BSS достиг объема около $1 млрд. Большую часть этой суммы (80%) сгенерировала «большая четверка» операторов: МТС, «Вымпелком», «Мегафон» и «Ростелеком». Из этого миллиарда $200-300 млн приходится на собственные разработки операторов, которые они ведут с привлечением внешних подрядчиков и системных интеграторов.
Остальная часть – около $750 млн, — поставки и услуги иностранных и российских вендоров. При этом лишь треть данной суммы – не более $240 млн, была потрачена на закупку новых OSS/BSS решений, в том числе на приобретение оборудования (30%) и услуги по внедрению (35%). То есть продажи телекоммуникационного программного обеспечения как такового составили порядка $84 млн.
Две трети от $750 млн в прошлом году российские телекоммуникационные компании потратили на поддержку и обслуживание своих OSS/BSS. В сегменте BSS российские операторы чаще всего покупали в 2013 году системы биллинга и CRM. В сегменте OSS — системы управления сетью (Network Management, Inventory), а также инструменты планирования и оптимизации сети (Planning, Provisioning, Network Performance).
В глобальном масштабе по прогнозу на 2012-2017 годы компании “Research and Markets” на рынке OSS/BSS этом сегменте доминирует три поставщика: Ericsson, Huawei Technologies Co. Ltd. и Nokia Solutions and Networks. Заметную долю также занимают компании Accenture и Amdocs Inc. Все эти компании также присутствуют на российском рынке наряду с локальными вендорами: «Ситроникс», Naumen, CBOSS. Ряд российских системных интеграторов играют на этом поле, разрабатывая программные продукты для операторов по их заказу.
«Российский рынок OSS/BSS отличается высокой конкуренцией и по цене, и с точки зрения требований, которые есть у клиентов – они хотят от предлагаемых решений гибкости и возможности локальной системной интеграции. ИТ-среда крупных федеральных операторов сложная, неоднородная, состоит из лучших глобальных и локальных программных решений со значительной частью собственных разработок. Главная задача, которая стоит перед ними сегодня – упростить и оптимизировать существующую OSS/BSS-архитектуру, консолидировать ее и дополнить компонентами, которые активно используются в западных компаниях, но отсутствуют на локальном рынке», — говорит Джозеф Дойл, директор по развитию решений в области BSS Ericsson в Восточной Европе и Центральной Азии. В качестве иллюстрации к свои словам он приводит повышенный интерес к методологии BSS/OSS-трансформации, а также к решениям по управлению клиентским опытом и управлению каталогом продуктов и заказов.
Если говорить о небольших региональных российских операторах, они обычно ограничены в бюджетах на масштабные ИТ, и вместо них используют в основном локально разработанные решения.
Большая часть функциональности, которую сегодня предлагают вендоры OSS/BSS уже хорошо исследована рынком и клиентами. Но некоторые инструменты, в частности, управление пользовательским опытом, пока еще слабо распространены. Решения данного типа помогают операторам следить за тем, чтобы пользователи на практике получали услуги хорошего качества на своих устройствах, вне зависимости от того, какие показатели производительности демонстрирует техническая инфраструктура. Это дает явные преимущества – сегодня главный фактор конкуренции на рынке связи – качество услуг. Но чтобы внедрить инструмент такого рода, требуется обеспечить взаимодействие широкого набора систем.
Джозеф Дойл отмечает также особенность подхода российских компаний к планированию – операторы в нашей стране сильно ориентированы на быструю окупаемость бизнеса и могут отказаться от внедрений OSS/BSS, если не увидят, что это быстро даст рост доходов.».
На сегодняшний день, по словам Джозефа Дойла, рынок данных решений в России характеризуется тремя аспектами. Российские потребители все больше стремятся контролировать свои счета. К примеру, в роуминге абоненты постоянно следят за расходами и хотят иметь возможность легко отключать услуги при необходимости, выбирать пакеты услуг и скорость соединения. «Мы также видим рост интереса к управлению качеством со стороны операторов: таким инструментам как Service Quality Management (SQM) и Customer Experience Management (CEM). Интерес к ним мы замечаем у компаний по всему миру: все потребители хотят получать услуги с надежным и быстрым соединением, и в особенности те, кто относится к категории VIP, для которых качество сервиса еще более важно. При этом в России есть центры с высокой плотностью населения, а также большие пространства, где довольно сложно обеспечить должное качество связи».
Второй аспект – покрытие. «В Москве потребители хотят получать качественные услуги, когда стоят в пробках на дороге. Если возникают проблемы с соединением, они обращаются к оператору, а мы помогаем ему справиться с подобными ситуациями. Вместе с операторами мы работаем над хорошим покрытием в городах. Чтобы этого добиться, нужны инструменты для сетевой оптимизации – автоматические или частично автоматизированные. И третье наблюдение – Россия огромная страна, отличающаяся высоким проникновением мобильной связи и тем, что в России необычайно много абонентов имеют две или три SIM-карты, используемые одновременно или попеременно.
Мы стремимся помогать операторам в управлении всеми этими процессами», — говорит Джозеф Дойл.
По прогнозу Transparency Market Research, глобальный рынок OSS/BSS будет расти на 16,2% каждый год, начиная с 2012 года и достигнет $48,5 миллиарда в 2018 году. В 2014 году, по прогнозу J’sonЪ» и Ericsson подписаться отписаться
Обзор программы Senet — управляем компьютерным клубом без проблем
[IT Friday] Сергей Калинин — Разработка и продвижение OSS/BSS системы для операторов связи
Источник: www.kommersant.ru
OSS/BSS системы

OSS/BSS системы (Operations Support Systems/Business Support Systems — системы поддержки операций/системы поддержки бизнеса) предназначены для комплексного управления телекоммуникационными ресурсами предприятия. Изначально подобные решения были всецело направлены на эксплуатационную поддержку телекоммуникационных сетей. Сейчас подобные бизнес-задачи решаются в рамках всего лишь одного из модулей современной OSS/BSS системы. Другие модули получили достаточно широкое распространение в энергетических, финансовых и транспортных компаниях.
Каталог OSS/BSS-решений и проектов доступен на портале TAdviser
![]()

Схема OSS/BSS системы
С развитием отрасли связи решающим фактором в конкурентной борьбе между операторами стали сервисы, которые они могут предоставить. Именно поэтому оперативность и качество услуг приобретают новое значение. В результате функциональность систем эксплуатационной поддержки телекоммуникационных сетей значительно расширилась, и появился новый класс ИТ-решений — OSS/BSS системы.
В последнее время OSS/BSS решения получили широкое распространение и в других отраслях, но доминирующее количество внедрений систем этого класса приходится именно на компании телекома. Учитывая роль телекоммуникационных сетей в бизнесе современного оператора, становится ясно, что их эффективная эксплуатация — одна из наиболее важных задач.
Современные OSS/BSS системы содержат множество модулей (классов) и подсистем, направленных на решение различных бизнес-задач. Сочетание различных классов с корпоративнымизаголовок ссылки информационными системами (CRM, HelpDesk и др.) обеспечивает необходимую функциональность для решения конкретных вопросов [1] .
Модули
ИТ-инфраструктура постоянно усложняется. Весь этот регулярно меняющийся и растущий вычислительный комплекс, комплекс сетей связи и систем жизнеобеспечения необходимо поддерживать и обслуживать. Без средств автоматизации решить эту задачу невозможно, так как человеческие ресурсы, как правило, ограничены. Средством автоматизации ручного труда, в данном случае, являются системы операционной поддержки. Эта аббревиатура объединяет несколько подклассов систем, включая мониторинг (Fault Management), сбор и анализ производительности (Performance Management), медиацию (сбор данных от разнородного оборудования и приведение их к общему виду), SIEM (Security Information and Event Management) сбор и обработка данных от средств информационной безопасности и ряд других систем [2] .
Системы OSS, как правило, не живут в замкнутом мире. Они взаимодействуют с разного рода аналитическими решениями класса, например BI, для того чтобы дать сводную картину того, как функционирование ИТ или телекома, или обеспечивающей инфраструктуры сказывается на конкретном бизнес-процессе. Эти решения показывают, что именно необходимо изменить в инфраструктуре, чтобы оптимизировать деятельность предприятия, и помогают оценить, насколько качественные услуги оказаны конечному потребителю.
По оценкам экспертов, несмотря на постоянное совершенствование технологий связи, потери от мошенничества в телекоммуникационных компаниях достигают 3–10% от общего оборота. Примечательно, что для большинства организаций этот показатель колеблется в пределах 5–7%. Одним из наиболее важных классов OSS/BSS системы является Fraud Management, что дословно переводится как «управление мошенничеством».
Модуль Fraud Management, предназначенный, в первую очередь, для операторов связи, обеспечивает обнаружение, пресечение и предотвращение случаев несанкционированного доступа к ресурсам оператора. Оснащенная средствами мониторинга для различных типов соединений, система реагирует в случае вызова подозрительного номера, несуществующего пользователя или несанкционированного доступа к услугам.
Средствами Fraud Management строится профиль каждого абонента (частота, длительность звонков, время их совершения, основные направления вызовов и т.д.), после чего система сопоставляет полученные усредненные параметры с текущими и передает документированную аналитику по ситуации с рекомендациями о последующих действиях. Подобное решение позволяет не только оперативно предотвратить все случаи несанкционированного использования ресурсов оператора связи, но и выработать определенный механизм защиты на основе проведенного анализа. Эксперты также отмечают, что тесная интеграция Fraud Management с CRM-решением позволяет максимально оперативно и эффективно построить защиту от мошенничества.
Кроме класса Fraud Management, очень большое значение имеет модуль Fault Management Service Provisioning Management)и широко известные WorkFlow-системы, предназначенные для управления территориально-распределенными командами сотрудников. Средства WorkFlow Management обеспечивают также мониторинг и составление аналитических отчетов в режиме реального времени.
Аналитики различают несколько возможных способов построения OSS/BSS решения на предприятии. Так или иначе, каждый вариант сводится к интеграции различных классов OSS/BSS с другими информационными системами и/или классами. Это может быть Fault managementhttps://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:OSS/BSS_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B» target=»_blank»]www.tadviser.ru[/mask_link]
Биллинговые системы будущего, и как они изменяют рынок связи
Сотовые операторы уже несколько лет находятся на перепутье. Услуги по передаче голоса и смс быстро устаревают. Традиционный бизнес теряет рентабельность. Основной целью стал поиск новых товаров и услуг, которые помогут остаться на острие прогресса и бизнеса.
Операторы отказываются от названия «поставщик мобильной связи» и приходят к гордому «поставщик цифровых услуг» или даже «lifestyle enabler». Аналитики пишут, что это одно из проявлений глобальных процессов, которые характерны для многих отраслей экономики. Мы же подойдем к этому с прикладной стороны и объясним, почему это у телекома все так резво получается и что еще получится впереди.

В основе деятельности оператора связи лежит BSS (Business Support System) — комплексное решение для обслуживания деловых бизнес-процессов, софтверное сердце операторского бизнеса. В числе задач BSS – распознать, тарифицировать, посчитать клиента, предоставить ему услуги, выставить счет, принять оплату и сделать это так, чтобы всем было приятно. Даже этот перечень уже выглядит внушительно. А сейчас, с развитием операторского бизнеса BSS непрерывно усложняются и берут на себя все новые задачи. Когда-то это были отправка служебных смс и формирование допустимых отрицательных лимитов, а сейчас, например, еще и продвинутый адвайзинг, подсказки новых тарифов, индивидуальные предложения новых услуг.
При этом с инженерной точки зрения системы стремятся к упрощению. Операторы заинтересованы в том, чтобы стоимость поддержки BSS росла не так быстро, как ее функциональность. В идеальной картине мира вендор предлагает оператору максимум функциональности при минимальной сложности решения. Хорошие BSS дают оператору возможность снизить затраты на эксплуатацию, не допускать сакрализации персонала, легко менять отдельные функциональные блоки и наращивать возможности бизнеса с помощью обновлений.

По данным консалтинговой компании J’son если нет – ее существенно изменяют или полностью заменяют. Так все выглядит в идеале.
А теперь спустимся на землю. Много ли есть счастливых и беззаботных телеком-операторов? Они постоянно находятся в движении — слияния, поглощения, периоды взрывного роста, замедление этого роста, развитие новых направлений. На планомерное и углубленное развитие BSS в таких условиях не остается ресурсов. В итоге собирается целый багаж проблем: трудная интеграция, избыточная НСИ, функциональные провалы и большое количество кастомного кода.
Что оператору хочется получить после всех этих потрясений? Комплексную платформу, на которой можно быстро выстроить end-to-end процессы. О трансформации классических биллинговых систем в digital-платформы говорили много лет, и вот требования начинают оформляться. Прежде всего среди маст-хэвов упоминается конвергентность, горизонтальная масштабируемость, поддержка облачных и гибридных моделей развертывания. Отдельным блоком стоят требования к «фронтам»: оператору жизненно важно общаться со своим клиентом везде, где он бывает, – в соцсетях, по SMS, через мессенджеры, личный кабинет, мобильное приложение и т.д.
Среди важных бизнес-требований также выдвинуты возможность создания супербандлов и тесная интеграция с партнерскими платформами. Партнеры так же важны для оператора, как и клиенты – они формируют ассортиментную экосистему оператора и дают ему дополнительную возможность зарабатывать. Наконец, самое главное требование к BSS — это улучшение показателя TTM (time-to-market).
Все это должно быть собрано в прозрачную, легко интегрируемую и конфигурируемую «коробку», которая обеспечит оператору адаптацию к активно изменяющимся требованиям бизнеса при сохранении низкого ТСО.
Взгляд разработчиков
Потребности операторов понятны, но вот с технической реализацией BSS есть разногласия. Главное из них — вопрос «абсолютного каталога». На счет того, должен ли каталог быть абсолютным, среди вендоров и операторов нет единого мнения. Пока предпочтительнее смотрится многоуровневая система каталогов и квази-каталогов:
- технический, в связке с контуром начислений и биллинга,
- каталог в структуре ордеринга,
- товарный, работающий в слое e-commerce с выходом на ритейл-площадки и маркетплейсы.

Решая проблему каталогов, необходимо учитывать множество вопросов. К самым сложным из них относятся вопросы бандлирования. Они решаются с помощью большого пула правил по доступности и назначению абоненту продуктов, акций, партнерских и комплексных услуг, а также специальному ценообразованию при наборе бандла. Например, оператор продает смартфон по цене 10 тысяч рублей.
И отдельно — тарифный план за 1 тысячу рублей в месяц. Купив вместе смартфон и тариф, покупатель заплатит 9 тысяч и три месяца будет получать в подарок пакет трафика 5 ГБ. А если еще купит беспроводные наушники за 5 тысяч, то получит красивый шарик. А в прошлом месяце оператор за наушники дарил горшок без меда. А в следующем будет дарить, скажем, шаланду, полную кефали.
Не важно, что — важно, чтобы правила применялись автоматически, в заданное время и по штатному алгоритму взаимодействия с OMS и модулем начислений. С такой важной функциональностью каталог становится основным инструментом в вопросе сокращения TTM. Так что, решив вопрос идеального каталога, вендор решает главную задачу оператора.
Будущее BSS
Что будет определять развитие BSS в ближайшем будущем? Сам клиент. А с технической стороны — различные технологии сбора и анализа данных о нем. Здесь самое место таким нашумевшим вещам как big data, machine learning, IoT. BSS не сможет пассивно прятаться за обслуживанием традиционной связи.
Без широких аналитических и предиктивных возможностей для персонализации система не сможет обслуживать digital-задачи оператора.

Работа с персональными предпочтениями клиентов приведет к распространению индивидуальных предложений по структуре бандлов и ценам. Затем начнется всеобщая эра кросс-продаж — удивительных по нынешним меркам кампаний. Например, оператор, РЖД и контент-провайдер сделают совместную акцию для пассажиров «сапсанов» и других скоростных поездов. Или выяснится, что человек уже 10 лет является и абонентом оператора, и клиентом «Перекрестка». На такой юбилей положен презент по совместной программе лояльности: юношам — суперкод для World of Tanks от оператора, девушкам — кулинарная книга Джейми Оливера от гипермаркета.
Выход в официальное пространство систем удаленного здравоохранения наверняка побалует нас яркими кампаниями операторов и клиник типа «Проверь спину – получи инвайт на телемедицину!». Сюда же подключатся страхование, банкинг, развлекательные услуги — словом, все что позволит телеком-оператору именоваться lifestyle enabler.
BSS, выросшая из простейшего биллинга, расширяется по всем направлениям, следуя рынку и зачастую предвосхищая его. В ней найдут отражение все значимые этапы прогресса — цифровизация, IoT’зация, 5G… Рано или поздно телеком-разработчики будут не просто создавать биллинговые системы, а отвечать за «бэк-энд» огромного куска потребительского рынка.
Материалы для публикации предоставили главный аналитик «Петер-Сервис» Татьяна Атанова и главный системный архитектор корпоративных решений Алексей Семенюта.
- Блог компании Nexign
- Беспроводные технологии
- Разработка систем связи
- Биллинговые системы
Источник: habr.com
Драйвер для бизнеса или что такое BSS
Решения BSS позволяют бизнесу выходить “за рамки” стандартного обслуживания и использовать любую полученную о клиентах информацию для повышения среднего чека, улучшения качества услуг, предотвращения оттока абонентов и привлечения новых. Поговорим о том, что такое BSS и так ли они нужны современным операторам.
Системы категории BSS (Business Support System) ─ это решения, поддерживающие взаимодействие с абонентами: тарификацию, управление продажами, маркетинг, обработку платежей. Это так называемые “деловые” процессы, которые помогают бизнесу не просто поддерживать стандартную деятельность, а по максимуму работать с информацией: персонализировать предложения, собирать, хранить и обрабатывать данные, быстро выпускать новые акции.
К BSS относят конвергентный биллинг, CRM, системы класса ERP.
Что такое BSS ─ подробнее о функциях
Пример. Первый оператор связи исправно выполняет свои функции: предоставляет связь, рассчитывает абонентов, дает доступ к сервисам, активирует и блокирует доступы.
При этом у компании слабое представление о целевой аудитории и предпочтениях пользователей, нет возможности сложного пакетирования услуг, отсутствует возможность квотирования балансов и их приоритезации. Второй же оператор связи не просто выступает поставщиком услуг, но и активно участвует в жизни абонентов: собирает и анализирует любимые сервисы пользователей, их увлечения, и потом на основе информации составляет индивидуальные “вкусные” предложения, на которые соглашаются большинство клиентов. Оператор предоставляет абонентам сложные пакеты услуг, а новые предложения и акции выводит на рынок, опережая конкурентов. Также у оператора связи есть портал самообслуживания пользователей.
В чем отличие этих двух операторов? Второй эффективнее работает с клиентской базой благодаря функционалу решения BSS.
Функции подсистемы BSS
- Сложная тарификация;
- Адвайзинг;
- Рекомендации новых тарифов;
- Подбор персональных предложений на основе информации о пользователе;
- CRM;
- Продуктовый каталог;
- Сложное пакетирование услуг;
- Квотирование и приоритезация балансов;
- Глубокий анализ массивов данных;
- Разработка и запуск новых продуктов;
- Управление ценообразованием;
- Выставление счетов, начисление оплаты, расчеты с абонентами (в том числе корпоративные, оптовые услуги, межсетевое соединение и роуминг);
- Декомпозиция заказа (например, разложение Triple Play).
Внедрение BSS ─ это не только повышение конкурентоспособности, но и снижение затрат на эксплуатацию, наращивание возможностей бизнеса. Посмотрите на новых операторов связи, которые выходят в “алый океан” и при этом все равно забирают приличный кусок абонентской базы: все это возможно только при качественной BSS, которая становится базой активного маркетинга и быстрого реагирования на изменения.
Источник: fw-t.ru