Field Device Self-Description via Local Non-Volatile Memory
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Field devices often require updated device descriptions to accommodate hardware and software revisions, but existing methods fail to ensure timely access to these descriptions, especially in remote locations without internet access, leading to device malfunctions and operational issues.
Innovation Solution
A field device with writeable non-volatile memory stores the correct device description, allowing for local updating and ensuring the device description is always available, even in remote locations, by utilizing existing memory blocks designed for firmware updates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If device descriptions are stored externally and require internet access for updates, then device configuration can be updated with latest revisions, but field devices in remote locations cannot access updated descriptions leading to operational failures
Solution Approach 1:
The field device stores multiple device descriptions locally in non-volatile memory before they are needed. When a device description is requested, the device checks its local storage and provides the appropriate version without requiring external access. This preliminary storage action ensures continuous operation even in remote locations without internet access.
Solution Approach 2:
The field device itself acts as an intermediary between the device description storage and the requesting system. Instead of requiring direct access to external servers, the field device maintains a local cache of device descriptions and serves requests from its own memory, eliminating the need for external connectivity.
2Loss of information
If device descriptions are downloaded from external sources, then latest device descriptions are obtained, but downtime occurs during download and installation
Solution Approach 1:
Device descriptions are downloaded and stored in non-volatile memory during manufacturing or initial setup, before the device is deployed to field locations. This preliminary action ensures that updated device descriptions are already available when the device is installed, eliminating the need for subsequent downloads that would cause downtime.
Solution Approach 2:
Multiple copies of device descriptions are stored in the field device's non-volatile memory. When a device description is needed, the system can immediately retrieve a local copy without requiring external downloads, thus eliminating downtime associated with downloading and installing device descriptions.
3Reliability
If multiple device descriptions are stored in non-volatile memory, then device descriptions are always available locally, but memory space is consumed
Solution Approach 1:
The non-volatile memory is segmented into multiple blocks, with each block capable of storing a complete device description. The system organizes these segments efficiently, storing only the necessary number of device description versions required for operational reliability, thus optimizing memory space utilization.
Solution Approach 2:
The system dynamically manages the number of device descriptions stored in memory based on available space and operational requirements. When memory is full, older or less critical device descriptions may be removed or archived, allowing the system to maintain reliability while adapting to memory constraints.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A field device (12) having a self-description is provided. The field (12) device includes loop communication circuitry (50) configured to communicate process information using a process standard communication protocol. A controller (60) is coupled to the loop communication circuitry (50) to communicate with one or more process devices using the loop communication circuitry (50). The controller (60) is coupled to a non¬ volatile, writeable, non-transitory computer readable medium (64) having a plurality of blocks (66, 68). A first block (66) contains device executable code, which when executed by the controller causes the field device to provide at least one process control function. A second block (68), at least as large as the first block (66), contains an electronic device description (70) of the field device.