Software dynamic deployment and monitoring method suitable for distributed embedded platform

Abstract

The invention particularly relates to a software dynamic deployment and monitoring method suitable for a distributed embedded platform. The method comprises the following steps: firstly, generating an application program according to a platform function requirement, and naming by adopting a rule of'function + node ID + core ID 'to ensure uniqueness; and establishing a mapping relation table between the application program and the node through an XML or JSON configuration file, and issuing the mapping relation table to each embedded node. And the nodes finish program deployment of the nodes and associated child nodes according to the table. Meanwhile, the system supports centralization and decentralization architecture, and the deployment state, the software operation state, the hardware state, the calculation load and the fault information are collected to the upper computer through a hierarchical reporting mechanism between the nodes. The upper computer can manage program distribution in an active or passive interaction mode, and the reliability is ensured by using a subpackage transmission and verification mechanism. According to the method, unified and flexible management and real-time monitoring of distributed embedded node program deployment and multi-dimensional operation states are realized.

Description

Technical Field

[0001] This invention relates to the field of radar technology, and more particularly to a software-based dynamic deployment and monitoring method for distributed embedded platforms. Specifically, this invention relates to a software-based dynamic deployment and monitoring method based on a distributed embedded platform, which can adapt to the addition or removal of embedded platform nodes, changes in the connection relationships between nodes, and changes in communication methods. The monitoring framework can monitor the deployment and operational status of each node in real time. Background Technology

[0002] Embedded platforms remain widely used in radar signal processing, especially in scenarios with extremely high timing requirements such as digital down-conversion, digital beamforming, and array control. Thanks to their strong real-time capabilities, embedded platforms will not be completely replaced by general-purpose processors like CPUs and GPUs in the short term. Most of these general-purpose processors have mature operating systems and file systems, executable files can be stored locally, and monitoring methods are relatively abundant. However, many embedded platforms currently lack operating systems or only have rudimentary real-time operating systems. Executable programs need to be remotely stored on non-volatile memory such as FLASH via a host computer. Some platforms even have multiple cores, each requiring different programs, making operations cumbersome and prone to errors when there are many nodes.

[0003] The overall efficiency of program deployment on embedded platforms is relatively low, and effective monitoring methods are lacking. Taking commonly used DSP and FPGA embedded platforms as examples, program deployment mainly relies on remote connection to the emulator for online updates. As the system scales up, the traditional one-to-one deployment method cannot meet the requirements, seriously affecting debugging and testing progress. Especially during field testing, in order to update the program on different nodes or check the running status, test personnel need to frequently get on and off the test vehicle to plug and unplug the emulator, which is not only inefficient but also poses safety hazards.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of the present invention, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] This invention provides a software-based dynamic deployment and monitoring method suitable for distributed embedded platforms, aiming to solve the technical problems of low program deployment efficiency, cumbersome operation and security risks, poor adaptability of deployment schemes, lack of comprehensive and effective status monitoring means, insufficient reliability of deployment process and high dependence on hardware environment in traditional distributed embedded platforms.

[0006] Other features and advantages of the invention will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0007] According to a first aspect of the present invention, a method for software-based dynamic deployment and monitoring suitable for distributed embedded platforms is provided, the method comprising: Step 1: Generate applications that meet the functional requirements of each platform, and name the compiled executable files according to rules to ensure file uniqueness; Step 2: Through a structured configuration file, clarify the correspondence between the application and each embedded platform node, generate a mapping table on the host computer containing node topology information, program correspondence and interaction logic, and send the mapping table to the embedded nodes; Step 3: Each node obtains the application information to be deployed for itself and its associated child nodes according to the received mapping table, and completes the deployment of the corresponding program; at the same time, each node reports the deployment status and running status information, wherein the status information of the child nodes is indirectly reported to the host computer through the central node to which they belong. Step 4: The host computer interacts with each node, executes program file distribution and deployment instructions, and monitors the status of each node in real time.

[0008] In some exemplary embodiments, in step 1, the rule-based naming adopts a combination of "function + node ID + core ID", and the named executable file is stored in a specified directory of the host computer.

[0009] In some exemplary embodiments, in step 2, the structured configuration file is an XML file or a JSON file.

[0010] In some exemplary embodiments, in steps 2 and 3, the communication and file transfer between nodes support both centralized and decentralized system architectures; for nodes that cannot be physically connected directly to the host computer, the acquisition of their program files and the reporting of their status information are relayed through one or more central nodes.

[0011] In some exemplary embodiments, when the host computer executes the program deployment, it employs one of the following two interaction logics: Proactive interaction: The host computer actively initiates program update commands and file transfers to the designated node; Passive interaction: The embedded node initiates a program update request to the host computer, and the host computer responds to the request and performs the corresponding file transfer.

[0012] In some exemplary embodiments, in the active and passive interactions, the transmission of program files adopts a packet mechanism, with each packet having a fixed size, and data verification and confirmation retransmission are performed during transmission to ensure the reliability of the transmission.

[0013] In some exemplary embodiments, the active interaction logic flow between the host computer and the embedded node is as follows: The host computer sends a program update command to a specified node, and the command contains the node's location information. After receiving the program update instruction, the node parses it and compares it with its own position; After the comparison is successful, the mapping relationship table is received, and the information in the relationship table is used to determine whether the child nodes need to be updated. The current node sends an acknowledgment message to the host computer; Once the host computer receives the confirmation message, it will switch to sending the executable program file data packet mode. If no confirmation message packet is received, the above process will be repeated. If no confirmation message packet is received after repeating 5 times, the program update will fail and the physical link will need to be checked. After the host computer enters the file sending mode, it needs to unpack the file, with each packet set to a fixed size, here 512 bytes; then it starts sending from the first packet. After receiving a data packet, the node performs verification and checks whether the data packets are consecutive. If a packet is erroneous, it is retransmitted. Once all data packets have been collected, determine whether they belong to the local node or a child node. If they belong to a child node, send them to the peer via PCIe.

[0014] In some exemplary embodiments, in step 4, the state includes deployment state, software running state, hardware state, computing load, and fault state.

[0015] In some exemplary embodiments, the status information and node location information involved in the status monitoring are reported and parsed through a predefined protocol format; wherein, the node location information is described using hierarchical identifiers.

[0016] In some exemplary embodiments, the hierarchical identifiers of the node location information include: rack ID, chassis ID where the board is located, slot ID where the board is located, and board ID.

[0017] According to a second aspect of the present invention, a storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the software-based dynamic deployment and monitoring method for distributed embedded platforms described in the first aspect.

[0018] According to a third aspect of the present invention, a computer program product is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, it implements the software-based dynamic deployment and monitoring method for a distributed embedded platform as described in the first aspect above.

[0019] According to a fourth aspect of the present invention, an electronic device is provided, comprising: Processor; and Memory for storing the executable instructions of the processor; The processor is configured to implement the software-based dynamic deployment and monitoring method for a distributed embedded platform as described in the first aspect above by executing the executable instructions.

[0020] The software-based dynamic deployment and monitoring method based on a distributed embedded platform provided by the embodiments of the present invention has the following advantages compared with the prior art: 1. Significantly Improved Deployment Efficiency: Breaking away from the traditional one-to-one program deployment mode of embedded platforms, this system generates a mapping table via a host computer and distributes programs in batches. Combined with a unique file naming rule of "function + node ID + core ID," it enables batch deployment of multi-node and multi-core programs. This eliminates the need for frequent plugging and unplugging of emulators by test personnel, significantly reducing manual operation costs, avoiding safety hazards, and accelerating debugging and testing progress, especially in field testing scenarios.

[0021] 2. High adaptability and flexible response to changing scenarios: Compatible with various system architectures such as "centralized" and "decentralized," it can flexibly adapt to the addition or removal of embedded platform nodes, changes in the connection relationships between nodes, and changes in communication methods. The deployment scheme can be dynamically adjusted according to the functional and computing requirements of different projects, fitting the complex and ever-changing application scenarios of distributed embedded platforms and reducing the cost of system expansion and modification.

[0022] 3. Comprehensive Monitoring Dimensions and Efficient Fault Location: A multi-dimensional real-time monitoring framework is constructed, covering key information such as deployment status, software running status, hardware status, computing load, and fault status. Through a precise node location method using "rack ID + chassis ID of the board + slot ID of the board + board ID," coupled with a status information classification and parsing mechanism, rapid fault location is achieved, providing developers with intuitive and convenient management tools and significantly improving debugging efficiency.

[0023] 4. Reliable transmission and stable deployment: The system incorporates both proactive and reactive interaction logics to meet the needs of different scenarios, such as initial deployment and program updates. File transmission employs a fixed-byte packet splitting, send / receive confirmation, and verification retransmission mechanism. Furthermore, it uses a built-in timer on each node to check the link's idle status, avoiding link collisions during multi-node deployments. This ensures the integrity and accuracy of executable program file transmission, guaranteeing a stable and reliable deployment process.

[0024] 5. Reduced system deployment and maintenance costs: It eliminates the need for complex operating systems or file systems on embedded platforms, adapting to embedded platforms without an operating system or with only a simple real-time operating system, thus reducing reliance on hardware environments. Simultaneously, remote deployment and centralized monitoring reduce the frequency and difficulty of on-site maintenance, lowering the overall deployment and maintenance costs throughout the system's lifecycle.

[0025] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0026] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention. It is obvious that the drawings described below are merely some embodiments of the invention, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0027] Figure 1 The image shows a method for dynamic monitoring of distributed deployment of applications proposed in this invention.

[0028] Figure 2 The diagram shown is a schematic representation of a node distribution drawn for ease of explanation in an example of the present invention.

[0029] Figure 3 The diagram shows the active interaction logic between the host computer and the embedded node in the deployment method proposed in this invention.

[0030] Figure 4 The diagram shows the passive interaction logic between the host computer and the embedded node in the deployment method proposed in this invention. Detailed Implementation

[0031] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the invention will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0032] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0033] The following are the core technical problems existing in the program deployment and status monitoring process of current distributed embedded platforms: 1. Inefficient program deployment, cumbersome operation, and security risks: Traditional embedded platforms (such as DSPs and FPGAs) often lack mature operating systems or only have simple real-time operating systems. Executable programs need to be remotely burned to non-volatile memory via a host computer. Furthermore, some platforms are multi-core architectures, requiring separate program deployment for each core. As system scale increases, the one-to-one deployment model (relying on remote connection to the emulator for online updates) cannot meet the requirements. Especially during field testing, test personnel need to frequently get on and off the test vehicle to plug and unplug the emulator, which is not only cumbersome and inefficient, severely impacting debugging and testing progress, but also poses security risks.

[0034] 2. Poor adaptability of deployment schemes, making it difficult to cope with changes in scenarios: In the application scenarios of distributed embedded platforms, it is common to add or remove nodes, change the connection relationship between nodes, and change the communication method. In addition, there are different system architectures such as "centralized" and "decentralized". Traditional deployment methods lack flexibility and cannot adapt to the above dynamic changes. As a result, when the system is expanded or modified, the deployment scheme needs to be redesigned, which is costly and time-consuming.

[0035] 3. Lack of comprehensive and effective status monitoring methods, making fault localization difficult: Traditional embedded platforms lack a unified monitoring framework, making it impossible to centrally monitor key dimensions such as deployment status, software running status, hardware status, computing load, and fault status. Furthermore, unclear node location identification makes it difficult to quickly locate problematic nodes and fault types when system failures occur, leading to prolonged debugging cycles and impacting system stability.

[0036] 4. Insufficient reliability in the deployment process, posing transmission risks: Traditional deployment methods lack robust interaction logic and data verification mechanisms, making them prone to data loss and verification failures during file transfer. Furthermore, the lack of link conflict avoidance mechanisms when deploying multiple nodes simultaneously may lead to deployment failure. In addition, the limited communication methods between the host computer and nodes fail to meet the needs of different scenarios such as initial deployment and program updates.

[0037] 5. High dependence on hardware environment and limited scope of application: Traditional deployment methods rely on the complex operating system or file system of embedded platforms. However, many embedded platforms (especially in the field of radar signal processing) have no operating system or only a simple real-time operating system, which makes it difficult for traditional methods to adapt and limits their scope of application, increasing the limitations and costs of system deployment.

[0038] To address the shortcomings and deficiencies of existing technologies, this example embodiment provides a software-based deployment method based on a distributed embedded platform. The method includes: generating applications that meet the functional requirements of each platform; defining the correspondence between the applications and platforms using XML or JSON files, generating a mapping table, and distributing it to the embedded nodes; each node deploying its own program and its associated child nodes according to the specified mapping, while simultaneously reporting its status information to the host computer; and the child nodes reporting their status information to their central node. The host computer and each node interact to complete the executable program deployment function.

[0039] refer to Figure 1 As shown, the specific steps may include: Step S101: Generate an application that meets the functional requirements of each platform; Step S102: Use XML or JSON files to clarify the correspondence between the application and the platform, generate a mapping table on the host computer and send it to the embedded node; In step S103, each node completes the program deployment of its own node and its associated child nodes according to the specified mapping relationship, and reports the status information to the host computer. The child nodes report the status information to their central node. In step S104, the host computer interacts with each node to complete the executable program deployment function and monitor dimensions such as deployment status, software running status, hardware status, computing load, and fault status.

[0040] The steps in this exemplary embodiment will now be described in more detail with reference to the accompanying drawings and embodiments.

[0041] In step S101, an application that meets the requirements is generated according to the functional requirements of each platform. After the application is compiled, the executable file is named according to certain rules to ensure the uniqueness of the file. Currently, the naming method of "function + node ID + core ID" is used. The named executable file is stored in the specified directory of the host computer.

[0042] In step S102, each node retrieves the topology of the embedded platform nodes from the mapping table, along with the name of the application to be deployed on the current node and the interaction logic between the node and the host computer and its parent and child nodes. This mapping table can be configured using, but is not limited to, XML or JSON files. The host computer may not have a direct physical connection to every node; some nodes may only obtain executable files through other central nodes, and status information also needs to be reported through these central nodes. Ideally, each node could communicate directly with the host computer, but this is not the case for cost reasons. Currently, this method is compatible with various connection methods between nodes, including both centralized and decentralized system architectures.

[0043] Ideally, each node can communicate directly with the host computer; this is a simplified decentralized model. The configuration file includes: the current node's location information, including rack ID + chassis ID of the board + slot ID of the board + board ID, etc.; the core IDs and corresponding executable file names of each core in the current node; whether it is a central node or a subordinate node of the central node; the location information of subordinate nodes (or the central node) (if they exist); the core IDs and corresponding executable file names of each core in the subordinate node (if they exist); the status bits of the current node; the status bits of subordinate nodes (or the central node), etc.

[0044] In step S103, the central node communicates with the host computer, and other nodes communicate with the central node to complete the program deployment function. In order to cope with executable program files of different sizes, the size of a single transmission can be fixed at 512 bytes or 1024 bytes. The sending and receiving of each data packet must be confirmed and verified. If the verification fails or is not received, it must be retransmitted. After the transmission is completed, the status is reported through the specified status bit.

[0045] The host computer, on the one hand, downloads the mapping table and corresponding executable application files to each node, and ensures correct file reception through interactive logic. On the other hand, it receives deployment status, software running status, hardware status, computing load, and fault status feedback from each node, thus monitoring the deployment and functional status of each node. The host computer can initiate communication with each node, or a node can request the host computer to send the names of the executable files required by the current node and its associated nodes. After verifying the validity of the request, the host computer begins the file transfer.

[0046] In step S104, the host computer interacts with each node to complete the executable program deployment function and monitor dimensions such as deployment status, software running status, hardware status, computing load, and fault status. Different status information reports require different function words, and the status reporting protocol is filled in the format of function + location information + value.

[0047] Figure 2 The diagram shown is a node distribution illustration for ease of explanation in this invention. In the diagram, the host computer and each central node can communicate directly via a network, while there is no network between the central nodes and their child nodes; communication is only possible via PCIe. In this invention, the program deployment method can be divided into two types: active interaction logic and passive interaction logic. Generally, passive interaction logic can be used. After the embedded platform powers on, it sends a request to the host computer. The host computer receives the request, compares it with the locally stored file, and completes the corresponding executable program file transfer and embedding process after confirming that everything is correct. In some cases, if a program update fails or the user wants to update to the latest version of the program, active interaction logic can be used. The host computer directly sends the executable program file to a designated node. After the designated node confirms that its location information is correct, the executable file transfer and embedding process is completed.

[0048] To make the solution of the present invention clearer, the following is in conjunction with the appendix. Figure 3 The present invention will be described in detail below. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the present invention. Figure 3 The diagram illustrates the active interaction logic between the host computer and the embedded node in the deployment method proposed in this invention. The specific process is as follows: S1: The host computer sends a program update command to the specified node, which includes the node's location information.

[0049] S2: After receiving the program update instruction, the node parses it and compares it with its own position.

[0050] S3: After the comparison is successful, receive the mapping relationship table and determine whether to update the child nodes based on the information in the relationship table.

[0051] S4: The current node sends an acknowledgment message to the host computer.

[0052] S5: The host computer receives the confirmation message and then switches to sending the executable program file data packet mode. If no confirmation message packet is received, the above process is repeated. If no confirmation message packet is received after repeating 5 times, the program update fails and the physical link needs to be checked.

[0053] S6: After the host computer enters the file sending mode, it needs to unpack the file, with each packet set to a fixed size, here 512 bytes. Then, it starts sending from the first packet.

[0054] S7: After receiving a data packet, the node performs verification and determines whether the data packets are continuous. If a packet is erroneous, it is retransmitted.

[0055] S8: After all data packets are received, determine whether the file belongs to the local node or a child node. If it belongs to a child node, send it to the peer node via PCIe.

[0056] S9: If it is the current node, the program will be flashed.

[0057] S10: Report the current node or its child nodes' status information.

[0058] S11: After the child node receives all the data packets, it performs FLASH hardening.

[0059] S12: Send status information indicating whether the data has been successfully applied to the parent node.

[0060] Figure 4 The diagram illustrates the passive interaction logic between the host computer and embedded nodes in the deployment method proposed in this invention. It's important to note that the process is essentially the same as the active interaction logic, except that the initiator is the embedded node. This method is suitable for scenarios involving the initial software update of an embedded platform. When an embedded node is updating its program, other embedded nodes are in a waiting state. To prevent collisions, each embedded node has an internal timer to check if the current link status is idle.

[0061] The software-based dynamic deployment and monitoring method for distributed embedded platforms provided by this invention includes: generating applications that meet the functional requirements of each platform; clarifying the correspondence between the application and the platform using XML or JSON files, generating a mapping table on the host computer and distributing it to the embedded nodes; each node completing the program deployment of itself and its associated child nodes according to the specified mapping relationship, and simultaneously reporting status information to the host computer, while the child nodes report status information to their central node. The host computer and each node interact to complete the executable program deployment function and monitor dimensions such as deployment status, software running status, hardware status, computational load, and fault status. It is adaptable to the addition or removal of embedded platform nodes, changes in the connection relationships between nodes, and changes in communication methods. The deployment scheme can be flexibly adjusted according to the functional and computational requirements of different projects, fitting the current ever-changing deployment scenarios. The monitoring framework can monitor the deployment and running status of each node in real time. As a management tool, it is both intuitive and convenient, and can quickly locate faults, helping developers improve debugging efficiency.

[0062] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0063] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.

[0064] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is defined only by the appended claims.

Claims

1. A method for software-based dynamic deployment and monitoring suitable for distributed embedded platforms, characterized in that, The method includes: Step 1: Generate applications that meet the functional requirements of each platform, and name the compiled executable files according to rules to ensure file uniqueness; Step 2: Through a structured configuration file, clarify the correspondence between the application and each embedded platform node, generate a mapping table on the host computer containing node topology information, program correspondence and interaction logic, and send the mapping table to the embedded nodes; Step 3: Each node obtains the application information to be deployed for itself and its associated child nodes according to the received mapping table, and completes the deployment of the corresponding program; at the same time, each node reports the deployment status and running status information, wherein the status information of the child nodes is indirectly reported to the host computer through the central node to which they belong. Step 4: The host computer interacts with each node, executes program file distribution and deployment instructions, and monitors the status of each node in real time.

2. The method according to claim 1, characterized in that, In step 1, the regularized naming adopts the combination of "function + node ID + core ID", and the named executable file is stored in the specified directory of the host computer.

3. The method according to claim 1, characterized in that, In step 2, the structured configuration file is an XML or JSON file.

4. The method according to claim 1, characterized in that, In steps 2 and 3, communication and file transfer between nodes support both centralized and decentralized system architectures; for nodes that cannot be physically connected directly to the host computer, the acquisition of program files and the reporting of status information are relayed through one or more central nodes.

5. The method according to claim 1, characterized in that, When the host computer executes the program deployment, it adopts one of the following two interaction logics: Proactive interaction: The host computer actively initiates program update commands and file transfers to the designated node; Passive interaction: The embedded node initiates a program update request to the host computer, and the host computer responds to the request and performs the corresponding file transfer.

6. The method according to claim 5, characterized in that, In both active and passive interactions, the transmission of program files adopts a packet-based mechanism. Each packet has a fixed size, and data verification and confirmation retransmission are performed during transmission to ensure the reliability of the transmission.

7. The method according to claim 5, characterized in that, The active interaction logic flow between the host computer and the embedded node is as follows: The host computer sends a program update command to a specified node, and the command contains the node's location information. After receiving the program update instruction, the node parses it and compares it with its own position; After the comparison is successful, the mapping relationship table is received, and the information in the relationship table is used to determine whether the child nodes need to be updated. The current node sends an acknowledgment message to the host computer; Once the host computer receives the confirmation message, it will switch to sending the executable program file data packet mode. If no confirmation message packet is received, the above process will be repeated. If no confirmation message packet is received after repeating 5 times, the program update will fail and the physical link will need to be checked. After the host computer enters the file sending mode, it needs to unpack the file, and each packet is set to a fixed size, which is 512 bytes here; Then start sending from the first packet; After receiving a data packet, the node performs verification and checks whether the data packets are consecutive. If a packet is erroneous, it is retransmitted. Once all data packets have been collected, determine whether the file belongs to the local node or a child node. If it is a child node, it should be sent to the other end via PCIe.

8. The method according to claim 1, characterized in that, In step 4, the states include deployment state, software running state, hardware state, computing load, and fault state.

9. The method according to claim 8, characterized in that, The status information and node location information involved in the status monitoring are reported and parsed through a predefined protocol format; among them, the node location information is described using hierarchical identifiers.

10. The method according to claim 9, characterized in that, The hierarchical identifiers of the node location information include: rack ID, chassis ID where the board is located, slot ID where the board is located, and board ID.

Images