Joseph, I'd start with the INCOSE materials, http://www.incose.org/

Some good books are Systems Engineering can be found at Amazon. As well NASA and DOD have SE handbooks, Google will find those for you

I would recommend the NASA Space System Engineering website with a lot of stuff on it. NASA SE handbook is cool too.

Mark and Joseph, The NAVAIR SE Handbook is also a good starting point. http://goo.gl/eaHNN4 that fits in the SETR framework http://goo.gl/isdbsw

All good recommendations above. I would also drill deeper by saying that there are many flavors of systems engineering depending on where you are in the project/product life cycle and not all SE philosophies apply equally as well. For example, in the conceptual design phase (fuzzy front end of the design process) I would submit that many of the more established processes and procedures of a more hierarchical SE process such as the Waterfall methodology could actually impede the creativity and innovation necessary to develop and rapidly mature numerous ideas/concepts. Some industries, such as the software industry utilize a "Spiral" approach with more rapid prototyping and testing of numerous ideas.

Systems Engineering means many different things to different people. I would take a broad look at the various philosophies in general and try to find one that speaks to your specific needs.

The question is somewhat vague.

Are we referring to the support of a systems engineering effort at a company? support of systems engineering of a product in the sense of development approaches? Systems engineering can be strict or flexible, depending on the life cycle model selected (e.g. a waterfall model, a spiral model, etc.) and depending on the requirements (level of system complexity, level of regulation or requirements e.g. from government procurement policies, etc.), so that the support needs may vary. It has even been demonstrated that SE can be combined with Agile methodologies, but the general idea of course is to facilitate forward, lifecycle-wide, system-wide thinking in order to reduce the overall costs of developing, producing, operating, maintaining, and retiring/disposing of a complex system (or any system, to that effect). Methods for support of a systems engineering mindset within an organization or of enforcing systems engineering practices in the organizations would probably include overall cost comparison and evaluation of the system's complexity and its "ilities" (reliability, manufacturability, maintainability, etc.) so as to demonstrate with the use of models and information displays to management that the cultural/organizational change is viable and desirable for the organization in the long term.

Dear all,

I have been preparing a text, and I think it exactly fits for the current question. The following experts can help to understand the question (as I read) and one line of research (from many active lines).

...

Object Management Group (OMG) and the International Council on Systems Engineering (INCOSE) developed Systems Modeling Language (SysML); a general-purpose modeling language for systems engineering applications. SysML has demonstrated a capability for top-down design refinement for large-scale systems; therefore, SysML is expressive, but the lack of formal foundations in the SysML results in imprecise models.

A major current focus in systems engineering is how to introduce precision in the approaches based on SysML through formal methods. This introduction can be a legal requirement when dealing with safety-critical systems; e.g., the IEC 61508 (Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems) defines formal methods as highly recommended technique for the highest safety integrity level; moreover, DO-178C (Software Considerations in Airborne Systems and Equipment Certification) addresses formal methods as a complement to testing. There are languages with a formal semantics such as Esterel or the B-language; nonetheless, there are no modeling languages with widespread use in systems engineering community that have the attraction of SysML.

...

There is a large number of research papers about semantics for models defined using UML, and consequently, SysML. Hußmann proposed the following classification for approaches concerning structural semantics: (1) naive set-theory, (2) meta-modeling, and (3) translation.

...

I hope it can help.

Best Regards,

Alessandro Romero.

I like your question, regrettably the answer probably results in further questions. It really depends on what stage or aspect you wish to cover. SSM is a very helpful approach to shape or bound the problem space or the programme designed to tackle the problematic situation. It is a good approach to engage with stakeholders and design a 'system' relevant to the problem and useful to capture requirements. Oval mapping or cognitive mapping are also effective techniques for stakeholder engagement. System dynamics offers a way to building an understanding of causal relationships and enables you to develop a quantities, simulation perspective. Viable systems model is another approach which stems from cybernetics and is particularly helpful in creating a view of the complexity of interactions (controls and environment) at multiple organisational levels. Happy to help further. Kees

A lot of colleagues are mentioning UML or SysML, but they don't really qualify as formal methods. Formal is normally deeply rooted or even direct part of mathematics. As such, bith UML and SysML or special representations of graphs (actually graphs with meaningful interpretations of node types and connection types, so we are talking about colored graphs). As system engineering transforms models into each other, model theory is a formal method to be applied as well.

In our recent journal paper, we addressed some of the implications (and applications) of related ideas: http://www.palgrave-journals.com/jos/journal/v7/n2/abs/jos20133a.html

Glen:

Yes, INCOSE is a great place to start.

However, there is a wide range of ideas about "formal systems approaches" in the INCOSE community. These ideas range from very informal "rules-of-thumb", through different types processes to math based techniques like Petri Nets and set theory.

The most formal approaches from the INCOSE community that I can find are:

-- Constraint Theory: Multidimensional Mathematical Model Management by George Friedman

-- Model-Based Systems Engineering by A. Wayne Wymore

Unfortunately, the names "constraint theory" and "model-based systems engineering" have been over-loaded with different approaches that appear to be more popular at this time.

Still looking...

Take care, be good to yourself and have fun,

Joe

Mark:

The NASA Systems Engineering material is excellent and focused on the mission of NASA.

While most of the material associated with NASA is process oriented, the real options technology evaluation method is a unique formal method for technology evaluation.

Most organizations do not have a technology development mission. However, the real options technology selection approach appears to be an excellent economic formal method.

Take care, be good to yourself and have fun,

Joe

Glen:

The NAVAIR SE Handbook is a work based on EIA 632. The handbook tailored the "Process for Engineering a System" to specifically fit the NAVAIR mission and regulations.

While the handbook is an excellent resource for NAVAIR projects, it is process based and enforced by organizational controls. Not the type of formal system engineering methods that I am seeking.

Take care, be good to yourself and have fun,

Joe

Charles:

Great information, thanks.

As you pointed out, I did not define systems engineering.

Which I will do now. From Klir "An Approach to General Systems Theory" page 101

"A special branch of the general systems theory, motivated solely by engineering aspects, was established in the 1950's under the name systems engineering."

This definition of systems engineering provides a unified concept that clearly separates systems engineering from specialty engineering. Formal methods that are used in systems engineering may be used in specialty engineering.

Take care, be good to yourself and have fun,

Joe

Ophir:

You are correct, the question is somewhat vague, by design.

The aspects of engineering a product that you have listed are all relevant.

Is there an intersection of the properties and aspects of all of these techniques?

Is there a common "formal systems engineering method" that applies generally in all cases.

I believe that there may be a few aspects that are common and may be viewed in a formal manner. These aspects may fall in to general categories of:

-- time allocation [sequence, concurrent, no-op]

-- value determination [type of value, source of value, value context]

-- organizational interface

Many of these aspects may be formulated as mathematical systems and viewed in a formal manner.

Take care, be good to yourself and have fun,

Joe

Johann:

And I agree with you, specifically in the quest for the "common threads" that may be reduced to mathematical and formal logic.

The risk management area is very interesting, especially the interface between program (project) management and technical management. At the most basic level the program manager focuses on three metric types, cost, schedule and technical.

These metrics have the following attributes;

--- Cost: linear, additive, common know unit of measure

--- Schedule: linear, additive, common know unit of measure

--- Technical: varies widely, need a technical expert to make the determination.

When the value system of the project manage is in widely varying units it is difficult to create a formal method. Therefore, program risk is almost always included at the program level to account for the lack of technical understanding.

INCOSE and IEEE have different views of the systems world but once each context is understood, then the material is valuable. The problem is knowing what to use in any given instance. Also, the formal nature of formal methods should help create repeatable outcomes.

Take care, be good to yourself and have fun,

Joe

Alessandro:

Great information, thanks.

The Model-Based Systems Engineering by A. Wayne Wymore uses set-theory.

Meta-modeling approaches need to have four general types of content:

-- Goals:

-- Ontology

-- Processes

-- Notations

UML and SysML are notations that lack support of similar process, goals and ontology sets. The flexibility of these notations may be one of their weak points,

Take care, be good to yourself and have fun,

Joe

Kees:

Yes, it is an open ended question, no simple one word answer.

The Soft Systems Methodology (SSM) is a good informal process to engage groups of individuals in structuring a system.

A more formal approach for the same activity is Warfield's Interpretive Structural Modeling (ISM) which uses a set of formal methods at its core.

System dynamics is also an excellent system structuring tool for informal process development.

Take care, be good to yourself and have fun,

Joe

Andreas:

Thanks for the pointer to the paper.

I could not access it, could you send me a copy or post it to this list?

I believe that formal graph theory is a key element in formal systems engineering methods. However, the semantics of the graphs need to align with the real-world system being modeled.

Take care, be good to yourself and have fun,

Joe

Mathematics

Robert:

Yes, mathematics is the basis of almost all formal methds.

Using the concept of general systems theory, the domain of systems engineering runs on a continuum from mathematics on the left to speciality engineering on the right.

It appears to me that formal systems engineering methods would include mathematics but not empirical orsubtantive data assocoated with a specific specially engineering domain.

This appears the leave the mathematics and systems approaches common to all industrial engineering applications as the ingredients of systems engineering formal methods.

The question is what are the common components and/or threads in this area?

Take care, be good to yourself and have fun,

Joe

Hi Joe, I haven't had a chance to read all the suggestions, but first I want to note (informally here) that there are several concepts of 'formal' in use; I favor the (1) mathematically-based formal methods, but there is a justification for (2) methodical processes that use thoughtfully defined (if not mathematically formal) elements and operations as in many simulation or rapid prototyping environments or that (3) have a body of rules and precedents as in Law. All of these types of "formal" have contributed and are contributing to methods in system engineering. In terms of mathematically-based methods, recently I had a chance to see how much progress has been made in terms of the scalability of formal methods and their use in capturing the systems engineering needed to design very large complex systems as part of the DARPA META program and for other similar enterprises in Europe.

One of the keys here is how to interweave the parts of the ongoing design and development and/or operations that can be appropriately captured with mathematically-based languages, with the judicious use of collected data, testing and other empirically-based methods combined with the thoughtfulness of the human system engineers/scientists. You might wonder why I am inserting system scientist into this discussion - because in real, complex systems there is often a lot that has not been determined yet and there are often scientific questions still being addressed in order to determine reasonable starting points for the design/parameterization/trade studies etc.

The role of the insightful, wise, experienced scientist/engineering is still critical, but even the best system scientist/engineer has to be supported by much better formal methods because the scale of our complex systems today is simply beyond the scope of even spot-checking by humans; we must be able to prove important behaviors/characteristics about large chunks of the system (the 80%) perhaps always requiring some wisdom for the remaining formidable parts.

Clearly, there is a lot more to say, but is this on target for your interests?

Kirstie:

You are correct in pointing out that there are a number of different types of "formal methods." One could define a formal method as a method for determining "truth."

As you point out, there is logical formal truth, empirical truth and value truth. Logical truth is in the area of mathematics. Empirical truth is in the area of scientific processes. Value truth is in the area of legal and social procedures and processes.

Systems engineering appears to have a need to work effectively with all three types of truth. Therefore, there may be a need for a "combined formal truth process" in systems engineering. This combined truth process would include aspects of formal truth, empirical truth and value truth.

I have created a small open source project located at: https://github.com/jjs0sbw/bsmp

That combines the formal truth (logical inference) and factual truth ( empirical data) to structure an unknown system. As this work develops I will add a value truth component.

Take care and have fun,

Joe

Hi Joe

I was pleased to see that you have been thinking about how to combine these notions of formal. I have done to a limited extent in several environments by allowing aspects of a problem to be appoached by several different kinds of methods (rulebases to get at what you were calling value truth, formal methods and simulations and databases to approach the other two) and then combning them based on domain expertise....clumsy and not elegant but going in the right direction. Best, Kirstie