Showing results for 
Search instead for 
Do you mean 

Application Lifecycle Management (ALM) and PLM: Working together ... and right on target

by Siemens Enthusiast Siemens Enthusiast ‎10-22-2014 02:40 PM - edited ‎03-31-2016 12:26 PM (3,870 Views)

Application Lifecycle Management (ALM)-Product Lifecycle Management (PLM) integration is evolving rapidly. In my previous blog article on PLM and ALM integration, I mentioned Siemens PLM and Polarion working together on a number of Teamcenter PLM-ALM integration use cases.

 

Application lifecycle management (ALM) and PLM roadmapAt the recent Polarion Live User Conference, in our “PLM and ALM Getting Together” keynote address, Stefano Rizzo, Polarion SVP of Strategy (pictured here) and I announced to more than 180 attendees our plans for the first phase of the integration.

 

Why do Siemens and Polarion believe that this integration will be different than others? It’s the first-ever integration between software engineering data and processes with product lifecycle management to provide consistent configuration of multi-domain data. Secondly, it’s the only end-to-end integrated ALM-PLM vision that also encompasses embedded software and Model-Based Systems Engineering (MBSE) aspects.

 

Additional benefits include:

  • Increased Productivity through closed-loop Software development with Product Lifecycle Management from inception to EOL
  • Improved Quality Assurance by making software engineering part of a MBSE environment for continuous software validation, leveraging modeling & simulation capability
  • Better Cost Containment with right first time software deliveries and reuse and closed-loop validation of software design decisions in the context of you overall products
  • Greater scalability from a proven enterprise infrastructure that requires minimal organizational adjustment

We're already getting feedback from analysts and customers that our ALM-PLM strategy is right on target:

 

PV2_Laila Hirr-CIMdataAnalyst.png

 

"Product complexity is increasing in all industries and manufacturers are striving to optimize processes and tools. To gain true efficiencies in product design, one integrated flow is needed that weaves together the mechanical, electronic and software development processes. The Polarion-Siemens partnership is bringing two of the process lanes together into an integrated solution within Teamcenter to facilitate these much needed efficiency gains." 

 

-- Laila Hirr, CIMdata High Tech Electronics Practice Manager 

 

 

 

  

PV2_Diego Lo Giudice_ForresterAnalyst.png

 

Diego Lo Giudice‏@dlogiudice Oct 14 #polarionlive Siemens is evolving teamcenter PLM to incorporate more ALM ; more #agile !!

 

 

 

 

 


PV2_Guido_Analyst.jpg

 

Guido‏@Yeti19_75 Oct 14

PLM and ALM together - the good stuff.continues #polarionlive

Retweeted by Polarion Software

 

 

 

 

Stay tuned for more announcements!

 

About the blogger: Pascal Vera is the product manager/evangelist for Mechatronics and Systems Driven Product Development initiatives and strategic planning.

 

Comments
by Siemens Dreamer Siemens Dreamer
on ‎10-30-2014 07:17 AM

The best-of-breed PLM ALM integration!

by Experimenter
on ‎02-10-2015 10:21 AM

Have a quick set of questions on this subject of ALM-PLM integration...

Is it really necessary to have mechanical, electrical/electronics and software all intertwined? Can software not hang on its own? How will software make a difference to the mechanical apsect of a design?

They can eventually come together in the final design unless there is a drastic change in requirements. This is my understanding or my 2 cents...

 

by Siemens Enthusiast Siemens Enthusiast
on ‎02-10-2015 02:56 PM

Racquetman-MN,

 

“All the really bad decision are made early in the project” (Simon Ramo - TRW) and ”bad things always happen at the interfaces”. 

 

In the ALM blog, we were referring to embedded systems and the software controlling and integrated with these systems. By definition embedded software has an intrinsic dependency to hardware (electronics, hydraulics, moving mechanical parts, etc.) and to the environment in which systems are evolving. There’s a 100 million lines of code in the average vehicle which is about 2 times the total code for Windows Vista, and more than 10 times what it takes to control the Mars Curiosity rover. Now volume isn’t necessarily the biggest issue, most of the time the issues focus on real-time acquisition of information. This information is needed to correctly manage the evolving behavior of non-software elements and ensure the expected behavior of the entire system. Something as conceptually simple as a car door lock/latch requires a closed-loop integration between software, electrical and mechanical to determine whether the transmission’s in drive, the car’s moving, how far has it moved, is the correct code being emitted by a nearby fob, is the latch up/down,  etc.

 

We used an automotive example, but all industries are experiencing another record number of recalls; 56 million vehicle recalls from January through October of 2014 and over 550 different consumer products. Most of those recalls relate to closed-loop, cross-discipline or cross-domain issues; problems that manifest themselves at the interfaces.  Letting software engineers work in standalone silos and waiting for software to be integrated at the end only perpetuates the paradigm that has caused bad things to happen at the interfaces. 

 

Pascal_V

by Experimenter
‎02-10-2015 08:19 PM - edited ‎02-10-2015 08:19 PM

Thanks Pascal...

I really like the explanation with the auto example...I understand things are intertwined but did not realize that software actually changed with mechanical and electrical changes.

 

Based on requirements, arent software requirements fixed to a point. I can see how mechanical and electrical, being hardware driven, they might change as designs evolve and change orders are written against them. But does requirements change so drastically that software is actually affected? I can if it is affected then software has to change. I feel that software is the virtual component that is evolving to its requirements but then it is brought together when unit and system testing is done. 

So, in your example, how far the car moved is detected by a sensor which triggers the code to latch the door. But the code is written without the need of knowledge of how the latch and door were designed, correct? But the mechanics of latch and door and whole car has to be in sync through the PD process and I can see why they have to be in sync. Software is somehow relying on triggers and they are coded approppraitely. Unless, of course, the triggers are  changing with each design of the car, latch and door...

Kind of still confused...I need to think a little bit more deeply...