Category: model-driven

  • Using Cursor AI as Architect and Modeler

    Cursor AI for dev-aware Architects and Modelers, produced using DALL-E, 2024-10-03

    Cursor AI with GitHub significantly improves my personal productivity and service portfolio. In-place coding and writing/blogging in one tool, awesome.

    As freelancer I am focusing on enterprise and IT architecture, customizing methods and modeling languages, and implementing integration of various tools like LeanIX, ARIS, MagicDraw, Confluence, Jira, Xray, ALM, and so on.

    This having said, programming can only be part of my job and it easily drains from my overall availability. So, I am really happy about any booster, be it other freelancers or better tooling. Moreover, since SysML v2 ad code-centric modeling approach is slowly entering the stage, I will be able to extend that productive approach even more.

    Cursor AI is so cool already, yet I would appreciate some improvements regarding different access scenarios

    • IDE: Cursor AI on Windows and Linux Desktops (UI, great)
    • Code: store all in GitHub repositories (storage layer)
    • Notes / Knowlege Base: store all as markdown files in one separate repository in GitHub (storage layer)
    • IDE anywhere: VSCode app for Android on Tablet accessing GitHub until Cursor AI becomes available (UI, mobile)
    • Git anywhere: GitHub for Android (read, search, mobile)

    It would also be nice to be able to add your own local LLM to the list improving data privacy even more.

    Google IDX beta also looks quite promising, based on VSCode for Web as well, but is sucking in all of your prompts and data…

  • Will MBSE Benefit from Textual Notation?

    Model-Based Systems Engineering (MBSE) is evolving, and a key question arises: Will MBSE benefit from textual notation? The answer is a resounding yes, but it is not the whole story. Graphical representations and much more are still needed. Here’s why.

    Textual Notation as a Complementary Tool

    Textual notation is already a fundamental aspect of many basic modeling tools. Languages like PlantUML and Mermaid derive graphical representations from textual descriptions, making it easier for engineers to visualize their models. Similarly, domain-specific languages (DSLs) like Franca IDL being integrated into modeling tools like MagicDraw have proven effective. These tools allow users to either code or draw, integrating seamlessly with other model content, providing flexibility and ease of use.

    The Emergence of Two-Way Solutions

    Advanced tools are taking this integration further. For instance, sophisticated tools like MagicDraw now offer two-way translations between SysML v2 textual notation and graphical representations. This functionality allows for editing on both sides, akin to how markdown plugins work in VSCode. Such advancements are critical as they cater to both textual and graphical preferences, ensuring broader acceptance and usability.

    Bridging the Gap Between Coders and Modelers

    Textual notations are particularly appealing to those who are closer to coding. For coders, the familiarity of textual input can significantly lower the barrier to entry into the modeling world. Integrating textual notations into Integrated Development Environments (IDEs) where coding happens can streamline workflows and enhance productivity.

    However, for managers, architects, designers, and analysts, graphical representations, output management, and comprehensive lists consistent with models are crucial. Therefore, to effectively engage both technical and non-technical stakeholders, providing a combination of textual notations and corresponding graphical representations is essential.

    Addressing Broader Needs

    Reflecting on over a decade of experience in automotive projects, it is clear that MBSE must address a range of needs to be truly successful and widely accepted. Models must encompass various aspects such as cross-product, cross-solution, product solutions, functional modeling, system architecture, software architecture, and boardnet modeling.

    Additionally, the existing model content in UML and SysML v1 predominantly features graphical representations. Transitioning to textual notations won’t happen overnight. The need for tool integration is paramount. The enterprise environment is a complex network of tools for planning, requirements, system modeling, simulation, test management, and implementation. Tool content is often replicated between neighboring tools or linked, necessitating seamless integration.

    Machine-Readable Models and Analytics

    Models that are not machine-readable are essentially ineffective, serving only as “marketing” diagrams. Ensuring that models are machine-readable and providing model analytics, such as making model content available to tools like Tableau, is highly valued by business users.

    Conclusion

    In conclusion, textual representation like SysML v2 is foundational and will significantly benefit MBSE. However, it must complement diagramming and address other critical needs to be truly effective. The standards are in place, and now it’s time for the tool business to catch up. By embracing both textual and graphical representations, and addressing the diverse needs of stakeholders, MBSE can achieve greater acceptance and success.

  • Exploring AI’s Impact on Jobs: Task-Based Analysis

    DALL·E 2024-05-31 18.19.33 - A futuristic workspace with a systems engineer working on a computer. The engineer is surrounded by holographic interfaces displaying elements aligned
    AI Integration in Systems Engineering, produced using DALL-E, 2024-05-31

    In the landscape of rapid technological advancement, the intersection of Artificial Intelligence (AI) and job roles is a topic of intense discussion. As Salman Khan insightfully points out in his new book “Brave New Words,” people aren’t replaced by AI but by individuals who leverage AI more productively. This perspective, while intriguing, calls for a deeper exploration of how AI impacts various job roles in today’s market.

    Understanding AI’s Impact on Systems Engineering

    One fascinating approach to gauge AI’s influence on jobs is proposed by There’s an AI for That. The website offers an ‘Impact Index’ for various job roles, including Software Engineer, Systems Engineer, Mechanical Engineer, and thousands of others. This index is calculated based on the number of AI applications that support tasks related to these roles. While specific and limited, this approach provides a more concrete perspective than speculative opinions like ‘I believe AI will never …’ or ‘Everybody will loose their jobs’ that are vague beliefs at best and sometimes even cause unnecessary alarm.

    Breaking Down Job Roles into Tasks

    To truly understand AI’s impact on jobs, it’s essential to break them down into their constituent tasks. For each task, we must examine whether AI can already support it effectively, whether AI needs refinement or regulation, or whether AI is currently incapable of supporting the task.

    Sal Khan’s book serves as a real eye-opener in this context illuminating what can be achieved in one year if you go all in. E. g., the one-on-one AI tutor called ‘Khanmigo’ initially gone live along GPT-4 shall not give the final answers right away, but instead guide the student step by step (a so-called Socratic tutor). It can summarize the learning process and give valuable feedback to the teacher incl. recommendations. It can even identify weak spots the teacher might wish to focus on. And it assists the teacher in creating lesson plans saving a lot of time and freeing resources.

    Drawing inspiration from this work, one could investigate systems engineering in a similar vein and develop an ‘MBSEamigo’ analogous to ‘Khanmigo’. The core idea here is to redefine roles based on tasks. In situations where role definitions vary, the strategy would be to identify common denominators and refine roles down to the tasks.

    For instance, consider the role of a systems engineer. This job can be broken down into approximately 1,000 tasks. Each task can then be assessed for AI impact. Here’s a glimpse into some typical tasks and their AI impact:

    • Running Coach: AI Impact: 100% | AIs: 12
    • Codebase Q&A: AI Impact: 95% | AIs: 9
    • Problem Solving: AI Impact: 90% | AIs: 15
    • Diagrams: AI Impact: 50% | AIs: 12
    • Data Protection: AI Impact: 50% | AIs: 4
    • Conversations with Clients: AI Impact: 50% | AIs: 1
    • Audits: AI Impact: 5% | AIs: 1
    • 3D Images: AI Impact: 5% | AIs: 22

    A Closer Look at Key Tasks

    Running Coach (AI Impact: 100%)

    In systems engineering, optimizing processes and workflows is crucial. AI tools can act as running coaches, continuously analyzing and improving these processes with precision and speed. For example, AI can automate routine checks and suggest improvements, ensuring systems run smoothly and efficiently.

    Codebase Q&A (AI Impact: 95%)

    AI-driven tools like code analyzers and automated testing frameworks significantly enhance codebase management. They can identify bugs, suggest fixes, and predict potential issues before they become critical, thereby reducing downtime and increasing productivity.

    Problem Solving (AI Impact: 90%)

    AI excels in problem-solving by offering data-driven insights and predictive analytics. For systems engineers, this means quicker diagnosis of issues and more effective solutions. AI can simulate various scenarios to find the most optimal solutions, saving time and resources.

    Applying Foundational Engineering Principles

    Incorporating AI into systems engineering must align with foundational engineering principles. This means ensuring that AI tools are used to enhance precision, reliability, and efficiency. Systems engineers should focus on maintaining robustness and accuracy in their projects while leveraging AI to handle repetitive and data-intensive tasks.

    To do this:

    • Verification and Validation: Regularly test AI tools to ensure they produce reliable and accurate results.
    • System Integration: Seamlessly integrate AI into existing systems without disrupting core functionalities.
    • Continuous Improvement: Use AI for ongoing analysis and optimization of engineering processes.
    • Documentation and Transparency: Keep thorough documentation of AI’s role and decisions in the engineering process for transparency and traceability.

    The Future of Systems Engineering with AI

    The journey of AI in systems engineering is just beginning. By continually refining AI tools and expanding their capabilities, we can create more efficient, innovative, and secure systems.

    As highlighted in Engineering.com, AI has the potential to revolutionize engineering by automating complex tasks, predicting system behaviors, and providing advanced analytics. Currently, using tools requires understanding how to manipulate and connect various elements, which involves tedious tasks like moving the mouse around. This repetitive work, similar to past challenges in the CAD world, is expected to be minimized in the future.

    SElive also identifies potential AI use cases. This integration not only boosts productivity but also fosters innovation by enabling engineers to focus on more strategic and creative aspects of system development. One notable example is the Technology Summarizer, which employs AI algorithms to analyze and condense vast amounts of technical documentation. This tool helps engineers quickly grasp essential information, stay updated with the latest advancements, and make informed decisions without being bogged down by extensive reading.

    The upcoming book “AI Assisted MBSE with SysML by Doug Rosenberg, Tim Weilkiens (mbse4u.com))” explores the integration of Artificial Intelligence in Model-Based Systems Engineering (MBSE) using the Systems Modeling Language (SysML). It highlights how AI can automate and enhance various MBSE tasks and provides methodologies along a comprehensive, step-by-step design of a Scanning Electron Microscope.

    Final Thoughts

    The integration of AI in the job market isn’t about replacement but about redefining roles and tasks so AI can be leveraged for increased productivity. The key lies in understanding AI’s impact on individual tasks and adapting job roles accordingly. As AI continues to evolve, our approach to integrating it into our workflows must also adapt, ensuring we stay ahead in this dynamic field.

    I am convinced that we will see a net job effect again as we have been seeing with automation. To the younger generations: experts are still needed. Do not let social media make you panic! Anybody can get anything out of ChatGPT, but only the expert speaks the sophisticated language of a discipline achieving much better results that also need to be curated by the very same expert.

  • Some Thoughts on MBE for Digital Threads

    This discussion emphasizes the importance of data-based engineering in the context of model-based (system) engineering, particularly in developing digital threads. Key principles proposed include prioritizing the system over data, integration over data islands, and data over visualization and documents.

    Schematic Tool Grid

    5-minute read:
    On MBE for Digital Threads

    Summary

    The “data” in context refers to that used in information systems contributing to the digital thread, more specifically, data in tools located within an engineering architecture framework along vertical and horizontal dimensions. Several tools are involved in this framework, each serving different functions and dimensions. For instance, MagicDraw refines budget-level vehicle functions into product use cases, while Codebeamer provides product requirements that help shape these use cases.

    The integration of these tools creates a grid that needs to be extended to account for other aspects such as the publication of model data and the development of test cases. While bundling combination cells into fewer tools like PLM can simplify this process externally, similar integration still occurs internally. Ultimately, this integrated tool grid should ideally reflect the productive systems, reinforcing the necessity of an integrated approach.

  • Domain-Specific Languages explained for Stakeholders

    Imagine you’re in a bustling professional kitchen. The heat, the noise, the coordinated chaos. This is a lot like software development, and you’re about to see why.

    Get your introduction to the concept and benefits of Domain-Specific Languages (DSLs). It’s quite a topic, but this culinary journey will make it, well, digestible.

    professional kitchen in a well-managed restaurant
    https://labs.openai.com/s/3mptF5d1dlDf7HmyqcgvCn1M

    5-minute read:
    Domain-Specific Languages explained for Stakeholders (mem.ai)

    Summary

    Amuse-Bouche (Software Development through Cooking): Welcome to the kitchen, where every role, from the head chef to the dishwasher, has a counterpart in a software development team.

    Appetizer (Recipes do change with Time): Just as orders in a kitchen can change based on customer feedback or ingredient availability, tasks in software development are also adjusted in response to feedback and constraints.

    Main Course (Managing Complexity for a growing Kitchen): As our kitchen grows, we need tools and techniques to manage the complexity. Imagine a Kitchen Modeling Language (KitchenML) that helps us coordinate all the moving parts.

    Dessert: Finally, let’s reflect on our journey. We’ve seen how a kitchen and a software development team can be similar, but also how they differ. One is physical and sequential, the other virtual and iterative.