The document discusses scheduling challenges for developing spacecraft subsystems with varying technology readiness levels (TRLs). Low TRL subsystems require more time for development but are often forced to keep pace with more mature subsystems. This can lead to inefficiency, schedule risk and cost overruns. To address this, the document proposes alternative scheduling approaches that decouple subsystem schedules, including staggered starts where subsystems define their own schedules, requiring low TRL subsystems to reach TRL 6 before integrating, and staggered finishes where subsystems can complete on independent schedules. It recommends assessing schedule risk at the subsystem level and analyzing the results to identify patterns to help select the best scheduling approach.
مبادرة
#تواصل_تطوير
المحاضرة الثانية والثلاثون من المبادرة مع
المهندس/ حسام قنديل
محاضر دولي ومستشار وباحث في إدارة المشروعات
بعنوان
" رؤية متجددة لتحليل المطالبات
Another perspective for Forensic Scheduling Analysis"
التاسعة مساء بتوقيت مكة المكرمة الأثنين13يوليو2020
وذلك عبر تطبيق زووم من خلال الرابط
https://us02web.zoom.us/meeting/register/tZcpd-2orz8vG9Wi8sfr51dZu95tUQ-DkeRl
علما ان هناك بث مباشر للمحاضرة على القنوات الخاصة بجمعية المهندسين المصريين
ونأمل أن نوفق في تقديم ما ينفع المهندس ومهمة الهندسة في عالمنا العربي
والله الموفق
للتواصل مع إدارة المبادرة عبر قناة التليجرام
https://t.me/EEAKSA
ومتابعة المبادرة والبث المباشر عبر نوافذنا المختلفة
رابط اللينكدان والمكتبة الالكترونية
https://www.linkedin.com/company/eeaksa-egyptian-engineers-association/
رابط قناة التويتر
https://twitter.com/eeaksa
رابط قناة الفيسبوك
https://www.facebook.com/EEAKSA
رابط قناة اليوتيوب
https://www.youtube.com/user/EEAchannal
رابط التسجيل العام للمحاضرات
https://forms.gle/vVmw7L187tiATRPw9
Real Time Systems,Issues of real time system,Notations, state oriented Petrinets,Milestones, Walkthroughs, Inspections, Test plans,Functional test,Performance test,Stress test,Structural test
Real-time systems are those systems in which the correctness of the system depends not only on the logical result of computation, but also on the time at which the results are produced.
Scheduling Task-parallel Applications in Dynamically Asymmetric EnvironmentsLEGATO project
Presentation by Jing Chen and Pirah Noor Soomro (Chalmers University of Technology) at the 16th International Workshop on Scheduling and Resource Management for Parallel and Distributed Systems (SRMPDS 2020) on 17 August 2020.
SRMPDS was a virtual event and collocated with ICPP’20 - 2020 International Conference on Parallel Processing.
Describes a model to analyze software systems and determine areas of risk. Discusses limitations of typical test design methods and provides an example of how to use the model to create high volume automated testing framework.
Grid scheduling is a process of mapping Grid jobs to resources over multiple administrative domains.
A Grid job can be split into many small tasks.
The scheduler has the responsibility of selecting resources and scheduling jobs in such a way that the user and application requirements are met,in terms of overall execution time (throughput) and cost of the resources utilized.
Software development practices & Infrastructure as Code - how well do they wo...Equal Experts
Infrastructure as Code (IaC) has rapidly become a key part of cloud native engineering. The hard gained experience from writing software can be applied to infrastructure, but fundamental differences means some fundamental approached need to be reconsidered. This talk will explore the implications for test driven development and build pipelines applied to IaC.
Jon Barber is an Engineer with Equal Experts.
He has been paid to write software for over 30 years, and has spent most of his time recently in the platform engineering space. He’s a keen advocate of XP values and practices, and sees himself more as an engineer than craftsman.
Similar to Battista barlowpmc conference 2012 rev. 2 (20)
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Assuring Contact Center Experiences for Your Customers With ThousandEyes
Battista barlowpmc conference 2012 rev. 2
1. All Subsystems Are Not Created Equal
Alternative Scheduling Approaches for Spacecraft Subsystem Development
Dewey E. Barlow
corina c. k. battista
February 2012 Orlando, FL
2. All Subsystems Are Not Created Equal
Contents
• Current NASA Environment
• Technology Readiness Level (TRL) Considerations
• Technology Race Analogy
• AO Process Implications
• Potential Solutions
• Staggered Starts
• MIN TRL6 First
• Staggered Finishes
• Recommendations
• Conclusion
3. All Subsystems Are Not Created Equal
Current NASA Environment
Used by permission.
4. All Subsystems Are Not Created Equal
Current NASA Environment (7120.5)
Figure 3.1 – NASA Project Lifecycle
5. All Subsystems Are Not Created Equal
TRL Considerations
When many subsystems are involved, the fact that the completion of an entire
spacecraft is more likely to be delayed due to the slippage in the development of
one immature subsystem is supported by historical evidence
6. All Subsystems Are Not Created Equal
TRL Considerations
It is difficult at best to predict the timeframes required for new and
emerging technology because:
• We have limited relevant historical data
• Even when relevant historical data exists, past performance may not be an accurate
indicator of future performance since new independent variables are constantly being
introduced
• Technology development is often an iterative process - We find out what works
often by eliminating what does not (Thomas Edison and the light bulb)
• Resource units are not highly correlated with duration
7. All Subsystems Are Not Created Equal
TRL Considerations
Since schedule requirements for technology development activities are subject to
variation and difficult to predict, how do we expect low TRL hardware to stay on pace
with proven technologies?
8. All Subsystems Are Not Created Equal
TRL Considerations
Forcing low TRL subsystems to keep pace with proven technologies can induce inefficiency
in execution, create schedule risk, and contribute to cost and schedule overruns
9. All Subsystems Are Not Created Equal
AO Process Implications
Compressing an already critical subsystem or instrument’s critical path may
provide an overly optimistic and ultimately unachievable timeframe for
development. Subsystems that have the most schedule risk have the least
amount of available schedule reserve
10. All Subsystems Are Not Created Equal
AO Process Implications
NASA projects are expected to comply with generally-accepted schedule
reserve guidelines so development timeframes for these already compressed
low TRL subsystems are reduced even further
11. All Subsystems Are Not Created Equal
Potential Solution 1 – Staggered Starts (SS)
What if we started with an unconstrained environment and allowed the subsystems and
instrument teams to define their schedule requirements given known resource
constraints and using adequate calculated schedule reserve commensurate with the level
of technical and execution risk?
12. All Subsystems Are Not Created Equal
Potential Solution 1 – Staggered Starts (SS)
Staggered Starts allows each subsystem to develop on their own schedule and achieve
compliance with 7120.5 through delta mission level reviews and waivers
13. All Subsystems Are Not Created Equal
Potential Solution 2 – MIN TRL First
The subsystems and instruments that are not at TRL 6 would be required to engage in
technology development and demonstration activities to achieve TRL 6 prior to engaging
all subsystems
14. All Subsystems Are Not Created Equal
Potential Solution 3 – Staggered Finishes
Staggered Finishes allows each subsystem to develop on their own schedule/deliver
early and achieve compliance with 7120.5 through delta mission level reviews and
waivers
15. All Subsystems Are Not Created Equal
Potential Solutions – Summary
All solutions involve some level of decoupling and decompression of
subsystem schedules
16. All Subsystems Are Not Created Equal
Recommendations
1 – Perform schedule risk assessments at the subsystem level to predict probable range
of deliveries
17. All Subsystems Are Not Created Equal
Recommendations
2 – Analyze data from schedule risk assessments to detect groupings or patterns
18. All Subsystems Are Not Created Equal
Conclusion
3 – Select the appropriate schedule approach
19. All Subsystems Are Not Created Equal
Example
Low
TRL
M
T
O P
High
TRL
M
O – Optimistic T
M – Most Likely
P – Pessimistic O P
T – Target (say 70%)
The Initial TRL Estimate Influences the Parameters of Probability Distribution on Delivery
20. All Subsystems Are Not Created Equal
Example OPL
FSW
PDU PSE RF NMS
Late Start Common Start Early Start
The Aggregate Probability Distribution Targets May Offer Patterns to Help Plan
Subsystem Schedule Development Approaches
Editor's Notes
Introduce ourselves and give a little bit background on where we work and what we do.
Outline the agenda. Note that the term subsystem will be used throughout this presentation to also represent instruments.
Need I say more? Basically captures that we are in a phase of trying to deliver more product for less $$. We’re not in a time of escalating budgets so we have to find creative ways to deliver more with less.
This captures the standard mission level reviews and phases for all NASA missions. I imagine that all of you have seen this chart before. The top row shows the NASA Lifecycle Phases. The second row captures project lifecycle phases such as A (Concept), B (Preliminary Design), etc. The Key Decision Points are captured in the third row while all of the mission level reviews are captured in the last row. All missions must pass these gates to make it to the next phase. The current environment promotes the notion of having all subsystems go through these gates at the same time. We will present alternate, different approaches to achieving these gates.
This graph capturesNASA’s standard definition of the 9 Technology Readiness Levels. We need to recognize that, from a scheduling perspective, significant variation may exist in TRLs at the subsystem level. Where that occurs, historical evidence suggests that the less mature TRL subsystems are likely to cause schedule delays. No mission starts with all subsystems at the same TRL level, and typically the subsystems with lower TRLs lag behind the ones with the higher TRL levels.
So we recognize that there is a varying TRL issue but here’s the problem. <Read the bullets.> The takeaway here is that it’s not easy to plan for varying TRLs.
While Dewey and I were debating the details of this TRL issue and potential solutions, we kept coming back to the issue as represented by a race. This is a simple graphic to show the crux of the problem. Effectively, the issue can be represented by a race with 3 participants. One raceris pushing a wheel barrow, one is riding a bike and one is on a motorcycle. These modes of transportation represent the disparity in TRLs that may occur on a mission. The participant on the motorcycle is obviously (barring any major issues like a blown tire) going to cross the finish line first with the wheel barrow pusher coming in last. The point here is that if all of these participants all start at the same time, we can’t realistically believe that they will finish at the same time. But currently, to pass the major mission milestone gates, they all need to be at the finish line ready to go. So the slower moving ones dictate the pace of completing the mission.
Effectively, subsystems that “get out in front” must either slow or suspend progress to pass the project review and KDP hurdles at the same time as the slowest subsystem. This creates inefficiency for the subsystems with schedule reserve since the project must bear the cost of carrying the subsystem resources (“marching army”) throughout the project or risk losing them to a competing project. This means that the slowest moving participant (often the subsystem with the lowest TRL) becomes the critical path. The other subsystems with higher TRLs tend to have more schedule reserve at the back end because they complete sooner thus giving them greater buffer. The takeaway here is that the subsystems which need the most schedule reserve (the ones with lower TRLs) end up having the least!
<Reference Andrew Chaikin speaking of not building the shuttle to technology but to cost.> A target launch date and phasing plan is often identified in the Announcement of Opportunity (AO) for major civilian spacecraft missions and bidders are encouraged15 to fit their schedules within the constraints of the launch date, regardless of the level of maturity of the major spacecraft subsystems. We then compound the problem by compressing an already tight critical path duration during the AO process. This compression shrinks the durations of all subsystems but those with sufficient reserve can adjust whereas the subsystems with the lower TRLs (and thus already shortened durations and even the CP) are now crunched even further. This adds risk that the execution of the CP and near-CPs because they become overly optimistic and potentially unachievable. In the end, the subsystems that have the most schedule risk have the least amount of available schedule reserve and the subsystems that have the least schedule risk have the most available schedule reserve. Less available schedule reserve means less cushion for the plethora of technological challenges that must be overcome to advance the technology to the next level and meet the requirements of the mission level review. Reference #15 = “Proposals that do not meet the specified mission level milestones identified in the AO may be considered non-responsive in accordance with Federal Acquisition Regulations (FAR)”.
NASA projects are expected to comply with generally-accepted schedule reserve guidelines <i.e. state JHU-APL reserve guidelines>.When schedule reserve is added to meet guidelines to show that there is buffer on the CP to cover the risk associated with the lowest TRL subsystem’s development cycle, this causes a compound compression of that already tight timeframe of the low-TRL subsystem. Ultimately, this adds more risk to that development flow. This compound compression can result in development timeframes at the subsystem level that are both unrealistic and unachievable and may ultimately result in cost and schedule overruns.
Dewey and I asked ourselves how major civilian space missions requiring the integration of complex subsystems can be achieved when the subsystems have varying TRLs. A staggered start approach places all subsystems on a theoretically equal schedule risk platform and would help to ensure that all spacecraft components arrive at the required time. We return to our race analogy. If we start with an unconstrained environment and allow the subsystems to define their schedule requirements given known resource constraints and using adequate calculated schedule reserve (where schedule reserve is commensurate with the technical and schedule risks and not prescribed by a guideline), then we could define a markedly different environment for project execution. From our previous race example, the uncompressed subsystem estimates become estimates based on detailed schedules and an associated risk analysis along the critical path of each schedule.
Since schedule development timeframes are based on unconstrained activity durations and schedule reserve is calculated based on known risks, our expectation is that this independent/unbiased estimate of development time would be more accurate and have a higher probability of success. With the goal that all subsystems ultimately deliver to a well-planned integration and test sequence in a timely fashion, the start dates for each subsystem would have to be staggered. In the current implementation environment, there is an additional complication by the fact that the distances vary by racer, and the racers are not completely independent of each other; however, it is possible to establish major reviews at the subsystem level (accelerated PDR, accelerated CDR, et al.) for the low TRL subsystems that must start earlier. An accelerated review would essentially be an early delta review that functions as the gate for the subsystem to pass to the next phase. The project level review (PDR, CDR et al.) can then be held based on the aggregate requirements of all other subsystems.
An alternate solution (a variation of the staggered start approach) is to perform an assessment of TRL near the start of the project for each subsystem. The subsystems whichare not currently at TRL6 would be required to engage in technology development and demonstration activities earlier to develop a functioning prototype in a ground environment (per the definition of TRL6). After all of the subsystems achieve this threshold for technological development, the traditional synchronized approach can be employed. As opposed to the staggered start approach, which morphs over time into the traditional approach, this approach requires that all subsystems pass a gate before full project participation can begin. This approach would be designed to advance the TRL of low TRL subsystems and minimize the variation in TRL prior to applying the traditional project execution approach. If we can minimize the variation in TRL we may be able to minimize the development timeframe at the project level.
A second alternate potential solution, and one that has been demonstrated on numerous occasions more by chance than forethought, is to allow higher TRL subsystems to finish early and “sit on the shelf” until required for spacecraft integration. This is the converse approach from the staggered start solution. The staggered finish solution allows all of the subsystems to start at the same time but relieves the requirement that they finish just in time for spacecraft integration and test. In an unconstrained schedule environment, we would be able to allow all subsystems to progress at their own rate based on TRL and deliver to “the shelf” when complete.
<Hand it over to Dewey to talk about benefits and deltas of each solution.>STAGGERED STARTS:There are several benefits to this approach. First, decoupling of the individual subsystem schedules from each other allows each the opportunity to start with an uncompressed schedule including a level of schedule reserve that is commensurate with the technical and schedule risk and significantly increases the likelihood of meeting the delivery date. When delays or potential delays occur in delivery by a subsystem, the project schedule may be impacted and the project must bear the cost of the delay. Next, when the subsystems march in unison to the next project gate they are paced by the slowest subsystem which induces inefficiency and additional costs since the marching army is being slowed by the low TRL subsystem or instrument. Finally, and most importantly, the project would have the benefit of starting out with an achievable cost and schedule baseline. Obviously, there are a significant number of additional factors that would have to be considered before utilizing this approach. For example, Interface Control Documents (ICDs) are developed to define the inputs and outputs of subsystems and to ensure that the designs of all subsystems are compatible. With a staggered start approach the design efforts on higher TRL subsystems may not have started when interface definitions may be required to continue to evolve the design of lower TRL subsystems that have started. Since the individual subsystems are not completely independent of each other, the development of subsystems would have to be monitored closely at the spacecraft level to ensure the orchestration and communication of spacecraft design parameters and interfaces are effectively managed.STAGGERED FINISHES:A major advantage of this approach may lie in our ability to freeze the designs from high heritage subsystems. What if we directed our subsystem lead engineers to build the box based on proven flight designs with as few changes as possible and then put this box aside as a flight ready spare? Based on test results from the flight spare we could then turn our attention to design changes aimed at performance improvement and build our engineering and flight models based on the modified design. If we ran into technical difficulty and lengthy delays in development we would have the flight spare to fall back on if we were unable to deliver the modified design within the projects timeframe. While on the surface this potential solution might eliminate the inefficiencies created by slowing down high TRL subsystems to meet their lower TRL counterparts, there are a number of concerns with this solution that warrant discussion. First, if we start out in a compressed schedule environment as described in paragraph 4, then the opportunity to deliver early is significantly reduced and the focus of our attention is naturally drawn to the low TRL subsystem development timeframe that may be difficult or impossible to compress. Next, there is really no such thing as high heritage. We must recognize that technology evolution is an ongoing process and, even to the extent that we may want to keep the design constant, external advancements in technology, parts, and sponsor requirements change. Even if we are able to escape external design change, we may not be able to resist the pressure for internal design change. We operate in a continuous improvement environment of spiral development (brassboard to breadboard to engineering model to flight model) and as the design matures we implement design changes that ultimately result in improved performance. If we provide engineers with proven tested designs they will evaluate the designs and attempt to improve on them. Finally, if we downsize the subsystem team and place our hardware “on the shelf” there is no guarantee that these personnel will be available for integration at the spacecraft level.