Data processing: structural design – modeling – simulation – and em – Simulating nonelectrical device or system
Reexamination Certificate
1999-04-25
2004-09-07
Jones, Hugh (Department: 2123)
Data processing: structural design, modeling, simulation, and em
Simulating nonelectrical device or system
C703S022000
Reexamination Certificate
active
06789054
ABSTRACT:
CROSS-REFERENCE TO RELATED APPLICATIONS
This application does not claim the benefit of prior patent applications. Relevant prior art is referenced in the section “Background of the Invention”.
BACKGROUND OF THE INVENTION
This invention relates to open development and run time environments of computer based systems, integrated system architectures, adaptive fuzzy systems, fractal geometry, and formal geometric computer languages.
In recent years, real time systems used in the services, process control, manufacturing, and military industries have grown into complex software-intensive systems composed of aggregates of physical processes, hardware processors, communication networks, software systems, human operators, and users. The following factors contribute to the inherent complexity of a complex system (Athans 1987, Varaiya 1993):
Distributed processing: A complex system requires a wide variety of physical communication interconnections. Distribution of its application functions is dictated by geographical distribution of user locations, economy of design, or high levels of processing loads.
Distributed databases: A complex system has many distributed databases which require stringent control algorithms for data integrity, transaction correctness, transaction atomicity, reconfiguration, and concurrency.
Real-time constraints: A complex system has real-time constraints which cannot be exceeded without causing severe system malfunctions. The vulnerability of real-time systems imposes adaptability requirements on their design and run time operation where system functions may be dedicated to a processor or allowed to migrate among different processors. This entails trade-off analysis of software complexity, reliability, and dynamic load balancing.
Large number of sensors: A complex system may be monitoring thousands or millions of distributed sensors with distributed functions for fail-soft operation, self-diagnosis, self-simulation, and self-correction. The time evolution of these sensors is subject to input/output timing and synchronization problems within the physical processes and their environment.
Large number of variables: A complex system is a strongly interacting multivariable system where a change in one input variable produces a change in many other variables. Input variables are almost always statistical and time variant.
Malicious and accidental interruptions: A complex system may be subjected to criminal activities, jamming of communication lines, or the partial destruction of any of their elements. Significant loss of human life, destruction of equipment, and loss of valuable information may result from malfunction of the sensor instrumentation, the processor hardware, or software.
Human-machine interactions: A complex system performance depends on the interaction between humans and machines performing together. Determination of the proper boundaries separating machines from human functions in a hazardous system environment does not remain static during the system life cycle.
Since the functional performance and reliability of complex systems depends strongly on their software design, major intellectual and financial investment has been directed to the development of tools including object-oriented methods, open programming environments, and life cycle development processes. Effective application of these tools to develop and sustain complex systems is limited by the lack of display methods and tools for the geometric specification and design automation of software systems. In the software world, it is generally acknowledged that the difficult part of building software intensive systems is in the requirements specification, design and testing of the conceptual construct underlying the system, and not in the labor of coding it and testing the fidelity of the generated code (Brooks 1987). This conceptual construct is the set of interlocking concepts: data sets, static and dynamic relationships among data items, algorithms, and invocation of system functions. Major causes of these difficulties are:
Invisibility and unvisualizability problems of software. These problems arise because it is currently perceived that software is not inherently embedded in space and as such has no ready geometric representation in the way that land has maps, a three dimensional physical object has an elevation, plan and side view projections, or a mechanical part has a scale drawing. The unvisuability of the software impedes the process of design within one mind and severely hinders communication among minds.
Complexity problems of software. These problems arise because of the very large number of software elements, states assumed by these elements and the nonlinear interaction between these elements. Technical complexity gives rise to communication problems among team members, which lead to product flaws, cost overruns, and schedule delays.
Changeability problems of software. These problems arise because the software product is embedded in a cultural matrix of applications, users, laws, etc. These may change continually and their changes force change upon the software product.
Conformity problems of software. These problems arise because of the many arbitrary human institutions and systems to which the software interfaces must conform.
The above problems are not resolved by traditional structured design tools or state of the art object oriented tools (Champeaux 1992, Desmond 1999). Both sets of tools fail to provide the necessary mechanisms for the specification, design automation, and test of the conceptual construct of real systems. When functional decomposition and structured design tools are employed several graphs are used to represent data and program hierarchical structures, data flow, control flow, and system state transition. When object oriented tools are employed several graphs, such as Class, Use case, Sequence, Collaboration, and State diagrams, are used to represent object inheritance, object relationships, flow of data, flow of control, patterns of dependency, time sequence, and data base structure. The current generation of both structured design and object oriented design tools suffers from a number of disadvantages:
They do not provide mechanisms for the visual integration of the different types of graphs used to specify object inheritance, object relationships, flow of data, flow of control, patterns of dependency, time sequence, and data base structure. Each of these graphs has different syntax and semantics. For any real system of a significant size, the lack of visual integration mechanisms hinders human assimilation, inspection and analysis of the logical construct underlying multiple views of a specified system.
Syntax and semantics of their graphs do not capture critical aspects of the system operational constructs such as system performance constraints, system security constraints, system reliability constraints, and system fault tolerant constraints.
Syntax and semantics of their graphs do not capture critical aspects of the system static and dynamic configuration constructs such as the geographical allocation of system resources to system nodes, and scheduling of system resources to meet evolving operational system requirements.
Their graphs do not provide visual geometric enforcement of system design semantics such as the spatial containment of system layered structure or its component objects within the geometric region of their container object
Their tools fail to provide an integrated geometric specification of the system logical construct. Their tools are not able to enact and adapt the system design to meet changing operational requirements.
The current generation of open programming environments and object oriented object design tools fails to create adaptive systems engineering tools. They fail to resolve invisibility, unvisualizability, complexity, changeability, resource constraints, dynamic scheduling, and spatial semantic problems of software intensive systems. Without a capability to create and capture unambiguous integrated geometric specification
Craig Dwin M.
Jones Hugh
White Mark P.
LandOfFree
Geometric display tools and methods for the visual... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Geometric display tools and methods for the visual..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Geometric display tools and methods for the visual... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3246584