RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
This page is under development
PandM is a CCSP component that implements core provisioning and management functionality of the device. Its primary role is to respond to commands from other CCSP components and protocol agents that need to set or query variables pertaining to provisioning and management. Its interface to other components uses the CCSP Message Bus interface and is based around a data model derived from TR-181 (TR-157, TR-143) along with CCSP specific extensions. PandM is a Key module which holds parameters related to many key services like: dhcpv6, LAN, DeviceInfo etc. It maintains a TR181 data model XML file with dbus object path as /com/cisco/spvtg/ccsp/pam . Has a layered architecture which makes it less complex for GET/SET implementation.
Figure 1 PandM Overview
sysevent set ipv4-tsip_IPAddress %s
sysevent set ipv4-tsip_Subnet %s
sysevent set ipv4-tsip_Gateway %s
sysevent set ipv4-resync_tsip %d
system("sysevent set wan_staticip-status stopped");
system("sysevent set wan_staticip-status started");
This is the architecture of PandM component:
Figure 2 PandM Architecture Overview
PandM consist of three layers:
1) Access Layer
Access Layer interfaces with the CCSP message bus and receives any set or get calls and passes them onto the DML layer to manage the data which is in request.
2) Data Model Management Layer
3) PandM HAL Integration (backend) Layer, a.k.a, component specific HAL
This is the layer making calls to underlying Linux system calls/commands, third party modules, open source modules and other CCSP components to execute the requests. This layer will be more component specific and will be providing APIs to CCSP so as to manage a particular hardware module of the system.
The implementation of APIs is responsible to convert the user space calls into Device IOCTL (kernel space) accordingly.
PandM DBUS object path is “/com/cisco/spvtg/ccsp/pam”.
PandM supports following CCSP Message Bus APIs:
PandM requires following CCSP Message Bus APIs.
From CR:
1) registerCapabilities
2) unregistername_space
3) unregisterComponent
4) discComponentSupportingNamespace
5) checkNamespaceDataType
6) SendDeviceProfileChangeSignal
From PA:
7) SendParameterValueChangeSignal
From PSM:
8) getParameterValues
9) setParameterValues
10) getParameterNames
Figure 3 Parameter Get Flow
Figure 4 Parameter Set Flow
Figure 5 PandM boot-up flow
Object instance number is used to uniquely identify the object, even across reboots. It is a special value PandM has to maintain, though it is not shown as a parameter. Instance number is generated when a new object is added, or during initialization, if no existing instance number is found. Generated instance number is saved in persistent configuration. Once the object is removed, the instance number is usually not reused.
Instance Number Operation Flow, when system boots up:
When an object is added during runtime: